ALT-PU-2024-18258-1
Package kernel-image-rt updated to version 6.1.91-alt1.rt31 for branch sisyphus in task 349231.
Closed vulnerabilities
Modified: 2026-03-04
BDU:2024-03934
Уязвимость функции packet_buffer_get() драйвера IEEE 1394 (FireWire) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-04-29
BDU:2024-03935
Уязвимость функции amdgpu_bo_move() драйвера amdgpu ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2024-03936
Уязвимость функции l2cap_chan_timeout() подсистемы Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2024-03937
Уязвимость функции sco_sock_timeout() подсистемы Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-04541
Уязвимость функции msft_do_close() реализации протокола Bluetooth ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2024-04546
Уязвимость функции do_setvfinfo() реализации стека протоколов TCP/IP ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2024-04551
Уязвимость функции net_alloc_generic() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-02-09
BDU:2024-04552
Уязвимость функции tipc_buf_append() реализации протокола Transparent Inter Process Communication (TIPC) ядра операционной системы Linux, позволяющая нарушителю, действующему удалённо, оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2024-04555
Уязвимость функции ip6_output() реализации протокола IPv6 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-04556
Уязвимость функции __fib6_rule_action() реализации протокола IPv6 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-09
BDU:2024-04557
Уязвимость функции tcp_twsk_unique() реализации протокола IPv4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-05-06
BDU:2024-04559
Уязвимость функции __spi_sync() драйвера Serial Peripheral Interface (SPI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-04561
Уязвимость функции sk_psock_verdict_data_ready() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-06521
Уязвимость компонента drm/amd/display ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-06522
Уязвимость компонента tcp ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-05-06
BDU:2024-07484
Уязвимость функции criu_restore_memory_of_gpu() драйвера amdkfd ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2024-10063
Уязвимость компонента dyndbg ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-10068
Уязвимость компонента at24 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-10588
Уязвимость функции __key_instantiate_and_link() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2024-10589
Уязвимость функций disable_show() и disable_store() драйвера USB ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2024-10674
Уязвимость компонента qibfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-10675
Уязвимость компонента phonet ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-10676
Уязвимость компонентов drm/qxl ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10678
Уязвимость компонента nl80211 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-10679
Уязвимость компонента core ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10680
Уязвимость компонента nfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2024-10681
Уязвимость компонента xdp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-09
BDU:2024-10682
Уязвимость функций bnad_debugfs_write_regrd() и bnad_debugfs_write_regwr() в модуле drivers/net/ethernet/brocade/bna/bnad_debugfs.c компонента bna ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2024-10683
Уязвимость компонента nsh ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-10684
Уязвимость компонентов s390/cio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10686
Уязвимость компонента core ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-30
BDU:2024-10687
Уязвимость компонентов s390/qeth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-10688
Уязвимость компонента bnx2fc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-09
BDU:2024-10690
Уязвимость функции iocg_kick_delay() в модуле block/blk-iocost.c компонента blk-iocost ядра операционной системы Linux, позволяющая нарушителю, действующему удалённо, оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2024-10691
Уязвимость компонента kasan ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10693
Уязвимость компонента mptcp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-29
BDU:2024-10694
Уязвимость компонента qca ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-10697
Уязвимость компонента h6 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-10700
Уязвимость компонентов net/smc ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
Modified: 2025-05-06
BDU:2024-10701
Уязвимость компонентов powerpc/pseries/iommu ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-10705
Уязвимость компонентов mm/slab ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-10709
Уязвимость компонента mm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-10711
Уязвимость компонента qca ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании (DoS)
Modified: 2025-05-06
BDU:2024-10726
Уязвимость компонентjd mm/hugetlb ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10747
Уязвимость компонентов drm/vmwgfx ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-10749
Уязвимость компонента devicetree ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
Modified: 2025-05-06
BDU:2024-10751
Уязвимость компонента octeontx2-af ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код с повышенными привилегиями
Modified: 2025-08-19
BDU:2024-10752
Уязвимость компонента tipc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10754
Уязвимость компонента vgic-v2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-10756
Уязвимость компонента lpfc ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-10-24
BDU:2024-10761
Уязвимость компонента ohci ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-10762
Уязвимость компонента hda ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-11526
Уязвимость компонентов fs/9p ядра операционной системы Linux, позволяющая нарушителю читать и манипулировать данными
Modified: 2025-05-06
BDU:2024-11583
Уязвимость компонента ks8851 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-02945
Уязвимость функции svdm_consume_identity() модуля drivers/usb/typec/tcpm/tcpm.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-12-08
BDU:2025-03052
Уязвимость функции lpfc_els_retry_delay() модуля drivers/scsi/lpfc/lpfc_els.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03062
Уязвимость функции cifs_pick_channel() модуля fs/smb/client/transport.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-04529
Уязвимость функции hv_uio_cleanup() модуля drivers/uio/uio_hv_generic.c - драйвера поддержки пользовательского ввода-вывода ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-06991
Уязвимость функции __vmbus_establish_gpadl() модуля drivers/hv/channel.c - драйвера поддержки гостевого режима Microsoft Hyper-V ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-03-19
BDU:2025-08066
Уязвимость компонентов mpi3mr_app.c, scsi_bsg_mpi3mr.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-08067
Уязвимость компонентов bloom_filter.c, bloom_filter_map.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-08068
Уязвимость компонента ioctl.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-08072
Уязвимость компонента channel.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным
Modified: 2026-03-19
BDU:2025-08073
Уязвимость компонентов hclge_main.c, hclgevf_main.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-08074
Уязвимость компонента gpiolib-cdev.c ядра операционной системы Linux, позволяющая нарушителю а также вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-08077
Уязвимость компонента hugetlb.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-22
CVE-2023-52882
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.
- https://git.kernel.org/stable/c/0b82eb134d2942ecc669e2ab2be3f0a58d79428a
- https://git.kernel.org/stable/c/70f64cb29014e4c4f1fabd3265feebd80590d069
- https://git.kernel.org/stable/c/7e91ed763dc07437777bd012af7a2bd4493731ff
- https://git.kernel.org/stable/c/9708e5081cfc4f085690294163389bcf82655f90
- https://git.kernel.org/stable/c/bfc78b4628497eb6df09a6b5bba9dd31616ee175
- https://git.kernel.org/stable/c/f1fa9a9816204ac4b118b2e613d3a7c981355019
- https://git.kernel.org/stable/c/fe11826ffa200e1a7a826e745163cb2f47875f66
- https://git.kernel.org/stable/c/0b82eb134d2942ecc669e2ab2be3f0a58d79428a
- https://git.kernel.org/stable/c/70f64cb29014e4c4f1fabd3265feebd80590d069
- https://git.kernel.org/stable/c/7e91ed763dc07437777bd012af7a2bd4493731ff
- https://git.kernel.org/stable/c/9708e5081cfc4f085690294163389bcf82655f90
- https://git.kernel.org/stable/c/bfc78b4628497eb6df09a6b5bba9dd31616ee175
- https://git.kernel.org/stable/c/f1fa9a9816204ac4b118b2e613d3a7c981355019
- https://git.kernel.org/stable/c/fe11826ffa200e1a7a826e745163cb2f47875f66
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
- https://security.netapp.com/advisory/ntap-20240912-0010/
Modified: 2026-01-22
CVE-2024-27398
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]
- https://git.kernel.org/stable/c/012363cb1bec5f33a7b94629ab2c1086f30280f2
- https://git.kernel.org/stable/c/1b33d55fb7355e27f8c82cd4ecd560f162469249
- https://git.kernel.org/stable/c/3212afd00e3cda790fd0583cb3eaef8f9575a014
- https://git.kernel.org/stable/c/33a6e92161a78c1073d90e27abe28d746feb0a53
- https://git.kernel.org/stable/c/483bc08181827fc475643272ffb69c533007e546
- https://git.kernel.org/stable/c/50c2037fc28df870ef29d9728c770c8955d32178
- https://git.kernel.org/stable/c/6a18eeb1b3bbc67c20d9609c31dca6a69b4bcde5
- https://git.kernel.org/stable/c/bfab2c1f7940a232cd519e82fff137e308abfd93
- http://www.openwall.com/lists/oss-security/2024/11/29/1
- http://www.openwall.com/lists/oss-security/2024/11/30/1
- http://www.openwall.com/lists/oss-security/2024/11/30/2
- https://git.kernel.org/stable/c/012363cb1bec5f33a7b94629ab2c1086f30280f2
- https://git.kernel.org/stable/c/1b33d55fb7355e27f8c82cd4ecd560f162469249
- https://git.kernel.org/stable/c/3212afd00e3cda790fd0583cb3eaef8f9575a014
- https://git.kernel.org/stable/c/33a6e92161a78c1073d90e27abe28d746feb0a53
- https://git.kernel.org/stable/c/483bc08181827fc475643272ffb69c533007e546
- https://git.kernel.org/stable/c/50c2037fc28df870ef29d9728c770c8955d32178
- https://git.kernel.org/stable/c/6a18eeb1b3bbc67c20d9609c31dca6a69b4bcde5
- https://git.kernel.org/stable/c/bfab2c1f7940a232cd519e82fff137e308abfd93
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DW2MIOIMOFUSNLHLRYX23AFR36BMKD65/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/OTB4HWU2PTVW5NEYHHLOCXDKG3PYA534/
- https://security.netapp.com/advisory/ntap-20240912-0012/
Modified: 2026-01-22
CVE-2024-27399
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]
- https://git.kernel.org/stable/c/06acb75e7ed600d0bbf7bff5628aa8f24a97978c
- https://git.kernel.org/stable/c/6466ee65e5b27161c846c73ef407f49dfa1bd1d9
- https://git.kernel.org/stable/c/8960ff650aec70485b40771cd8e6e8c4cb467d33
- https://git.kernel.org/stable/c/955b5b6c54d95b5e7444dfc81c95c8e013f27ac0
- https://git.kernel.org/stable/c/adf0398cee86643b8eacde95f17d073d022f782c
- https://git.kernel.org/stable/c/e137e2ba96e51902dc2878131823a96bf8e638ae
- https://git.kernel.org/stable/c/e97e16433eb4533083b096a3824b93a5ca3aee79
- https://git.kernel.org/stable/c/eb86f955488c39526534211f2610e48a5cf8ead4
- https://git.kernel.org/stable/c/06acb75e7ed600d0bbf7bff5628aa8f24a97978c
- https://git.kernel.org/stable/c/6466ee65e5b27161c846c73ef407f49dfa1bd1d9
- https://git.kernel.org/stable/c/8960ff650aec70485b40771cd8e6e8c4cb467d33
- https://git.kernel.org/stable/c/955b5b6c54d95b5e7444dfc81c95c8e013f27ac0
- https://git.kernel.org/stable/c/adf0398cee86643b8eacde95f17d073d022f782c
- https://git.kernel.org/stable/c/e137e2ba96e51902dc2878131823a96bf8e638ae
- https://git.kernel.org/stable/c/e97e16433eb4533083b096a3824b93a5ca3aee79
- https://git.kernel.org/stable/c/eb86f955488c39526534211f2610e48a5cf8ead4
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DW2MIOIMOFUSNLHLRYX23AFR36BMKD65/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/OTB4HWU2PTVW5NEYHHLOCXDKG3PYA534/
- https://security.netapp.com/advisory/ntap-20240926-0001/
Modified: 2025-12-23
CVE-2024-27400
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
- https://git.kernel.org/stable/c/0c7ed3ed35eec9138b88d42217b5a6b9a62bda4d
- https://git.kernel.org/stable/c/5c25b169f9a0b34ee410891a96bc9d7b9ed6f9be
- https://git.kernel.org/stable/c/9a4f6e138720b6e9adf7b82a71d0292f3f276480
- https://git.kernel.org/stable/c/d3a9331a6591e9df64791e076f6591f440af51c3
- https://git.kernel.org/stable/c/0c7ed3ed35eec9138b88d42217b5a6b9a62bda4d
- https://git.kernel.org/stable/c/5c25b169f9a0b34ee410891a96bc9d7b9ed6f9be
- https://git.kernel.org/stable/c/9a4f6e138720b6e9adf7b82a71d0292f3f276480
- https://git.kernel.org/stable/c/d3a9331a6591e9df64791e076f6591f440af51c3
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DW2MIOIMOFUSNLHLRYX23AFR36BMKD65/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/OTB4HWU2PTVW5NEYHHLOCXDKG3PYA534/
Modified: 2026-01-22
CVE-2024-27401
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.
- https://git.kernel.org/stable/c/1fe60ee709436550f8cfbab01295936b868d5baa
- https://git.kernel.org/stable/c/38762a0763c10c24a4915feee722d7aa6e73eb98
- https://git.kernel.org/stable/c/4ee0941da10e8fdcdb34756b877efd3282594c1f
- https://git.kernel.org/stable/c/539d51ac48bcfcfa1b3d4a85f8df92fa22c1d41c
- https://git.kernel.org/stable/c/67f34f093c0f7bf33f5b4ae64d3d695a3b978285
- https://git.kernel.org/stable/c/79f988d3ffc1aa778fc5181bdfab312e57956c6b
- https://git.kernel.org/stable/c/7b8c7bd2296e95b38a6ff346242356a2e7190239
- https://git.kernel.org/stable/c/cca330c59c54207567a648357835f59df9a286bb
- https://git.kernel.org/stable/c/1fe60ee709436550f8cfbab01295936b868d5baa
- https://git.kernel.org/stable/c/38762a0763c10c24a4915feee722d7aa6e73eb98
- https://git.kernel.org/stable/c/4ee0941da10e8fdcdb34756b877efd3282594c1f
- https://git.kernel.org/stable/c/539d51ac48bcfcfa1b3d4a85f8df92fa22c1d41c
- https://git.kernel.org/stable/c/67f34f093c0f7bf33f5b4ae64d3d695a3b978285
- https://git.kernel.org/stable/c/79f988d3ffc1aa778fc5181bdfab312e57956c6b
- https://git.kernel.org/stable/c/7b8c7bd2296e95b38a6ff346242356a2e7190239
- https://git.kernel.org/stable/c/cca330c59c54207567a648357835f59df9a286bb
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DW2MIOIMOFUSNLHLRYX23AFR36BMKD65/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/OTB4HWU2PTVW5NEYHHLOCXDKG3PYA534/
Modified: 2025-12-23
CVE-2024-35848
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.
- https://git.kernel.org/stable/c/26d32bec4c6d255a03762f33c637bfa3718be15a
- https://git.kernel.org/stable/c/2af84c46b9b8f2d6c0f88d09ee5c849ae1734676
- https://git.kernel.org/stable/c/6d8b56ec0c8f30d5657382f47344a32569f7a9bc
- https://git.kernel.org/stable/c/c43e5028f5a35331eb25017f5ff6cc21735005c6
- https://git.kernel.org/stable/c/c850f71fca09ea41800ed55905980063d17e01da
- https://git.kernel.org/stable/c/f42c97027fb75776e2e9358d16bf4a99aeb04cf2
- https://git.kernel.org/stable/c/26d32bec4c6d255a03762f33c637bfa3718be15a
- https://git.kernel.org/stable/c/2af84c46b9b8f2d6c0f88d09ee5c849ae1734676
- https://git.kernel.org/stable/c/6d8b56ec0c8f30d5657382f47344a32569f7a9bc
- https://git.kernel.org/stable/c/c43e5028f5a35331eb25017f5ff6cc21735005c6
- https://git.kernel.org/stable/c/c850f71fca09ea41800ed55905980063d17e01da
- https://git.kernel.org/stable/c/f42c97027fb75776e2e9358d16bf4a99aeb04cf2
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
Modified: 2025-04-04
CVE-2024-35947
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.
- https://git.kernel.org/stable/c/00e7d3bea2ce7dac7bee1cf501fb071fd0ea8f6c
- https://git.kernel.org/stable/c/343081c21e56bd6690d342e2f5ae8c00183bf081
- https://git.kernel.org/stable/c/3c718bddddca9cbef177ac475b94c5c91147fb38
- https://git.kernel.org/stable/c/41d8ac238ab1cab01a8c71798d61903304f4e79b
- https://git.kernel.org/stable/c/529e1852785599160415e964ca322ee7add7aef0
- https://git.kernel.org/stable/c/a66c869b17c4c4dcf81d273b02cb0efe88e127ab
- https://git.kernel.org/stable/c/a69e1bdd777ce51061111dc419801e8a2fd241cc
- https://git.kernel.org/stable/c/ba3c118cff7bcb0fe6aa84ae1f9080d50e31c561
- https://git.kernel.org/stable/c/00e7d3bea2ce7dac7bee1cf501fb071fd0ea8f6c
- https://git.kernel.org/stable/c/343081c21e56bd6690d342e2f5ae8c00183bf081
- https://git.kernel.org/stable/c/3c718bddddca9cbef177ac475b94c5c91147fb38
- https://git.kernel.org/stable/c/41d8ac238ab1cab01a8c71798d61903304f4e79b
- https://git.kernel.org/stable/c/529e1852785599160415e964ca322ee7add7aef0
- https://git.kernel.org/stable/c/a66c869b17c4c4dcf81d273b02cb0efe88e127ab
- https://git.kernel.org/stable/c/a69e1bdd777ce51061111dc419801e8a2fd241cc
- https://git.kernel.org/stable/c/ba3c118cff7bcb0fe6aa84ae1f9080d50e31c561
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/OTB4HWU2PTVW5NEYHHLOCXDKG3PYA534/
Modified: 2025-04-04
CVE-2024-35999
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)")
- https://git.kernel.org/stable/c/0fcf7e219448e937681216353c9a58abae6d3c2e
- https://git.kernel.org/stable/c/60ab245292280905603bc0d3654f4cf8fceccb00
- https://git.kernel.org/stable/c/8094a600245e9b28eb36a13036f202ad67c1f887
- https://git.kernel.org/stable/c/98c7ed29cd754ae7475dc7cb3f33399fda902729
- https://git.kernel.org/stable/c/0fcf7e219448e937681216353c9a58abae6d3c2e
- https://git.kernel.org/stable/c/60ab245292280905603bc0d3654f4cf8fceccb00
- https://git.kernel.org/stable/c/8094a600245e9b28eb36a13036f202ad67c1f887
- https://git.kernel.org/stable/c/98c7ed29cd754ae7475dc7cb3f33399fda902729
Modified: 2025-09-23
CVE-2024-36000
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.
- https://git.kernel.org/stable/c/4c806333efea1000a2a9620926f560ad2e1ca7cc
- https://git.kernel.org/stable/c/538faabf31e9c53d8c870d114846fda958a0de10
- https://git.kernel.org/stable/c/b76b46902c2d0395488c8412e1116c2486cdfcb2
- https://git.kernel.org/stable/c/f6c5d21db16a0910152ec8aa9d5a7aed72694505
- https://git.kernel.org/stable/c/4c806333efea1000a2a9620926f560ad2e1ca7cc
- https://git.kernel.org/stable/c/538faabf31e9c53d8c870d114846fda958a0de10
- https://git.kernel.org/stable/c/b76b46902c2d0395488c8412e1116c2486cdfcb2
- https://git.kernel.org/stable/c/f6c5d21db16a0910152ec8aa9d5a7aed72694505
Modified: 2025-01-06
CVE-2024-36012
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
- https://git.kernel.org/stable/c/10f9f426ac6e752c8d87bf4346930ba347aaabac
- https://git.kernel.org/stable/c/4f1de02de07748da80a8178879bc7a1df37fdf56
- https://git.kernel.org/stable/c/a85a60e62355e3bf4802dead7938966824b23940
- https://git.kernel.org/stable/c/e3880b531b68f98d3941d83f2f6dd11cf4fd6b76
- https://git.kernel.org/stable/c/10f9f426ac6e752c8d87bf4346930ba347aaabac
- https://git.kernel.org/stable/c/4f1de02de07748da80a8178879bc7a1df37fdf56
- https://git.kernel.org/stable/c/a85a60e62355e3bf4802dead7938966824b23940
- https://git.kernel.org/stable/c/e3880b531b68f98d3941d83f2f6dd11cf4fd6b76
Modified: 2025-12-17
CVE-2024-36017
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.
- https://git.kernel.org/stable/c/1aec77b2bb2ed1db0f5efc61c4c1ca3813307489
- https://git.kernel.org/stable/c/206003c748b88890a910ef7142d18f77be57550b
- https://git.kernel.org/stable/c/4a4b9757789a1551d2df130df23bfb3545bfa7e8
- https://git.kernel.org/stable/c/5e7ef2d88666a0212db8c38e6703864b9ce70169
- https://git.kernel.org/stable/c/6c8f44b02500c7d14b5e6618fe4ef9a0da47b3de
- https://git.kernel.org/stable/c/6e4c7193954f4faab92f6e8d88bc5565317b44e7
- https://git.kernel.org/stable/c/8ac69ff2d0d5be9734c4402de932aa3dc8549c1a
- https://git.kernel.org/stable/c/f3c1bf3054f96ddeab0621d920445bada769b40e
- https://git.kernel.org/stable/c/1aec77b2bb2ed1db0f5efc61c4c1ca3813307489
- https://git.kernel.org/stable/c/206003c748b88890a910ef7142d18f77be57550b
- https://git.kernel.org/stable/c/4a4b9757789a1551d2df130df23bfb3545bfa7e8
- https://git.kernel.org/stable/c/5e7ef2d88666a0212db8c38e6703864b9ce70169
- https://git.kernel.org/stable/c/6c8f44b02500c7d14b5e6618fe4ef9a0da47b3de
- https://git.kernel.org/stable/c/6e4c7193954f4faab92f6e8d88bc5565317b44e7
- https://git.kernel.org/stable/c/8ac69ff2d0d5be9734c4402de932aa3dc8549c1a
- https://git.kernel.org/stable/c/f3c1bf3054f96ddeab0621d920445bada769b40e
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-09-18
CVE-2024-36028
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:
- https://git.kernel.org/stable/c/2effe407f7563add41750fd7e03da4ea44b98099
- https://git.kernel.org/stable/c/52ccdde16b6540abe43b6f8d8e1e1ec90b0983af
- https://git.kernel.org/stable/c/7e0a322877416e8c648819a8e441cf8c790b2cce
- https://git.kernel.org/stable/c/9c9b32d46afab2d911897914181c488954012300
- https://git.kernel.org/stable/c/2effe407f7563add41750fd7e03da4ea44b98099
- https://git.kernel.org/stable/c/52ccdde16b6540abe43b6f8d8e1e1ec90b0983af
- https://git.kernel.org/stable/c/7e0a322877416e8c648819a8e441cf8c790b2cce
- https://git.kernel.org/stable/c/9c9b32d46afab2d911897914181c488954012300
Modified: 2025-11-04
CVE-2024-36031
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.
- https://git.kernel.org/stable/c/25777f3f4e1f371d16a594925f31e37ce07b6ec7
- https://git.kernel.org/stable/c/939a08bcd4334bad4b201e60bd0ae1f278d71d41
- https://git.kernel.org/stable/c/9da27fb65a14c18efd4473e2e82b76b53ba60252
- https://git.kernel.org/stable/c/ad2011ea787928b2accb5134f1e423b11fe80a8a
- https://git.kernel.org/stable/c/cc219cb8afbc40ec100c0de941047bb29373126a
- https://git.kernel.org/stable/c/e4519a016650e952ad9eb27937f8c447d5a4e06d
- https://git.kernel.org/stable/c/ed79b93f725cd0da39a265dc23d77add1527b9be
- https://git.kernel.org/stable/c/25777f3f4e1f371d16a594925f31e37ce07b6ec7
- https://git.kernel.org/stable/c/939a08bcd4334bad4b201e60bd0ae1f278d71d41
- https://git.kernel.org/stable/c/9da27fb65a14c18efd4473e2e82b76b53ba60252
- https://git.kernel.org/stable/c/ad2011ea787928b2accb5134f1e423b11fe80a8a
- https://git.kernel.org/stable/c/cc219cb8afbc40ec100c0de941047bb29373126a
- https://git.kernel.org/stable/c/e4519a016650e952ad9eb27937f8c447d5a4e06d
- https://git.kernel.org/stable/c/ed79b93f725cd0da39a265dc23d77add1527b9be
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
Modified: 2025-09-18
CVE-2024-36032
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.
- https://git.kernel.org/stable/c/57062aa13e87b1a78a4a8f6cb5fab6ba24f5f488
- https://git.kernel.org/stable/c/62d5550ab62042dcceaf18844d0feadbb962cffe
- https://git.kernel.org/stable/c/6b63e0ef4d3ce0080395e5091fba2023f246c45a
- https://git.kernel.org/stable/c/a571044cc0a0c944e7c12237b6768aeedd7480e1
- https://git.kernel.org/stable/c/cda0d6a198e2a7ec6f176c36173a57bdd8af7af2
- https://git.kernel.org/stable/c/57062aa13e87b1a78a4a8f6cb5fab6ba24f5f488
- https://git.kernel.org/stable/c/62d5550ab62042dcceaf18844d0feadbb962cffe
- https://git.kernel.org/stable/c/6b63e0ef4d3ce0080395e5091fba2023f246c45a
- https://git.kernel.org/stable/c/a571044cc0a0c944e7c12237b6768aeedd7480e1
- https://git.kernel.org/stable/c/cda0d6a198e2a7ec6f176c36173a57bdd8af7af2
Modified: 2025-09-30
CVE-2024-36880
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.
- https://git.kernel.org/stable/c/02f05ed44b71152d5e11d29be28aed91c0489b4e
- https://git.kernel.org/stable/c/1caceadfb50432dbf6d808796cb6c34ebb6d662c
- https://git.kernel.org/stable/c/2e4edfa1e2bd821a317e7d006517dcf2f3fac68d
- https://git.kernel.org/stable/c/427281f9498ed614f9aabc80e46ec077c487da6d
- https://git.kernel.org/stable/c/ed53949cc92e28aaa3463d246942bda1fbb7f307
- https://git.kernel.org/stable/c/02f05ed44b71152d5e11d29be28aed91c0489b4e
- https://git.kernel.org/stable/c/1caceadfb50432dbf6d808796cb6c34ebb6d662c
- https://git.kernel.org/stable/c/2e4edfa1e2bd821a317e7d006517dcf2f3fac68d
- https://git.kernel.org/stable/c/427281f9498ed614f9aabc80e46ec077c487da6d
- https://git.kernel.org/stable/c/ed53949cc92e28aaa3463d246942bda1fbb7f307
Modified: 2025-01-10
CVE-2024-36882
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
- https://git.kernel.org/stable/c/30153e4466647a17eebfced13eede5cbe4290e69
- https://git.kernel.org/stable/c/468971c3f4b8187f25334503b68050a0e1370147
- https://git.kernel.org/stable/c/7629ef6dda1564098aadeef38e5fbd11ee8627c4
- https://git.kernel.org/stable/c/cf6a1d16c6df3c30b03f0c6a92a2ba7f86dffb45
- https://git.kernel.org/stable/c/30153e4466647a17eebfced13eede5cbe4290e69
- https://git.kernel.org/stable/c/468971c3f4b8187f25334503b68050a0e1370147
- https://git.kernel.org/stable/c/7629ef6dda1564098aadeef38e5fbd11ee8627c4
- https://git.kernel.org/stable/c/cf6a1d16c6df3c30b03f0c6a92a2ba7f86dffb45
Modified: 2026-01-22
CVE-2024-36883
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.
- https://git.kernel.org/stable/c/0c3248bc708a7797be573214065cf908ff1f54c7
- https://git.kernel.org/stable/c/2d60ff5874aefd006717ca5e22ac1e25eac29c42
- https://git.kernel.org/stable/c/3cdc34d76c4f777579e28ad373979d36c030cfd3
- https://git.kernel.org/stable/c/7b0e64583eab8c1d896b47e5dd0bf2e7d86ec41f
- https://git.kernel.org/stable/c/9518b79bfd2fbf99fa9b7e8e36bcb1825e7ba030
- https://git.kernel.org/stable/c/a26ff37e624d12e28077e5b24d2b264f62764ad6
- https://git.kernel.org/stable/c/b6dbfd5bcc267a95a0bf1bf96af46243f96ec6cd
- https://git.kernel.org/stable/c/f4f94587e1bf87cb40ec33955a9d90148dd026ab
- https://git.kernel.org/stable/c/0c3248bc708a7797be573214065cf908ff1f54c7
- https://git.kernel.org/stable/c/2d60ff5874aefd006717ca5e22ac1e25eac29c42
- https://git.kernel.org/stable/c/3cdc34d76c4f777579e28ad373979d36c030cfd3
- https://git.kernel.org/stable/c/7b0e64583eab8c1d896b47e5dd0bf2e7d86ec41f
- https://git.kernel.org/stable/c/9518b79bfd2fbf99fa9b7e8e36bcb1825e7ba030
- https://git.kernel.org/stable/c/a26ff37e624d12e28077e5b24d2b264f62764ad6
- https://git.kernel.org/stable/c/b6dbfd5bcc267a95a0bf1bf96af46243f96ec6cd
- https://git.kernel.org/stable/c/f4f94587e1bf87cb40ec33955a9d90148dd026ab
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://security.netapp.com/advisory/ntap-20241018-0001/
Modified: 2026-01-22
CVE-2024-36886
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:
- https://git.kernel.org/stable/c/080cbb890286cd794f1ee788bbc5463e2deb7c2b
- https://git.kernel.org/stable/c/21ea04aad8a0839b4ec27ef1691ca480620e8e14
- https://git.kernel.org/stable/c/367766ff9e407f8a68409b7ce4dc4d5a72afeab1
- https://git.kernel.org/stable/c/66116556076f0b96bc1aa9844008c743c8c67684
- https://git.kernel.org/stable/c/93bc2d6d16f2c3178736ba6b845b30475856dc40
- https://git.kernel.org/stable/c/a0fbb26f8247e326a320e2cb4395bfb234332c90
- https://git.kernel.org/stable/c/e19ec8ab0e25bc4803d7cc91c84e84532e2781bd
- https://git.kernel.org/stable/c/ffd4917c1edb3c3ff334fce3704fbe9c39f35682
- https://git.kernel.org/stable/c/080cbb890286cd794f1ee788bbc5463e2deb7c2b
- https://git.kernel.org/stable/c/21ea04aad8a0839b4ec27ef1691ca480620e8e14
- https://git.kernel.org/stable/c/367766ff9e407f8a68409b7ce4dc4d5a72afeab1
- https://git.kernel.org/stable/c/66116556076f0b96bc1aa9844008c743c8c67684
- https://git.kernel.org/stable/c/93bc2d6d16f2c3178736ba6b845b30475856dc40
- https://git.kernel.org/stable/c/a0fbb26f8247e326a320e2cb4395bfb234332c90
- https://git.kernel.org/stable/c/e19ec8ab0e25bc4803d7cc91c84e84532e2781bd
- https://git.kernel.org/stable/c/ffd4917c1edb3c3ff334fce3704fbe9c39f35682
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://security.netapp.com/advisory/ntap-20241018-0002/
Modified: 2025-12-17
CVE-2024-36889
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:
- https://git.kernel.org/stable/c/39ca83ed73db9edcc6d70c0dc7a73085a4725012
- https://git.kernel.org/stable/c/592f69b41766d366dbb8ff4ef5a67c4396527bbe
- https://git.kernel.org/stable/c/99951b62bf20cec9247f633a3bea898338b9e5b4
- https://git.kernel.org/stable/c/aa0c07c1f20e05b30019bff083ec43665536f06f
- https://git.kernel.org/stable/c/dc941fec0719d0471a5902424d6b2a17df233193
- https://git.kernel.org/stable/c/fb7a0d334894206ae35f023a82cad5a290fd7386
- https://git.kernel.org/stable/c/39ca83ed73db9edcc6d70c0dc7a73085a4725012
- https://git.kernel.org/stable/c/592f69b41766d366dbb8ff4ef5a67c4396527bbe
- https://git.kernel.org/stable/c/99951b62bf20cec9247f633a3bea898338b9e5b4
- https://git.kernel.org/stable/c/aa0c07c1f20e05b30019bff083ec43665536f06f
- https://git.kernel.org/stable/c/dc941fec0719d0471a5902424d6b2a17df233193
- https://git.kernel.org/stable/c/fb7a0d334894206ae35f023a82cad5a290fd7386
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
Modified: 2025-10-29
CVE-2024-36890
In the Linux kernel, the following vulnerability has been resolved: mm/slab: make __free(kfree) accept error pointers Currently, if an automatically freed allocation is an error pointer that will lead to a crash. An example of this is in wm831x_gpio_dbg_show(). 171 char *label __free(kfree) = gpiochip_dup_line_label(chip, i); 172 if (IS_ERR(label)) { 173 dev_err(wm831x->dev, "Failed to duplicate label\n"); 174 continue; 175 } The auto clean up function should check for error pointers as well, otherwise we're going to keep hitting issues like this.
- https://git.kernel.org/stable/c/79cbe0be6c0317b215ddd8bd3e32f0afdac48543
- https://git.kernel.org/stable/c/946771c2a2b1150f9b7286feadc3aa1e15a1eb16
- https://git.kernel.org/stable/c/9f6eb0ab4f95240589ee85fd9886a944cd3645b2
- https://git.kernel.org/stable/c/ac6cf3ce9b7d12acb7b528248df5f87caa25fcdc
- https://git.kernel.org/stable/c/cd7eb8f83fcf258f71e293f7fc52a70be8ed0128
- https://git.kernel.org/stable/c/edca32f87329d6e341d2143a3b58ec254e8f6b88
- https://git.kernel.org/stable/c/79cbe0be6c0317b215ddd8bd3e32f0afdac48543
- https://git.kernel.org/stable/c/9f6eb0ab4f95240589ee85fd9886a944cd3645b2
- https://git.kernel.org/stable/c/ac6cf3ce9b7d12acb7b528248df5f87caa25fcdc
- https://git.kernel.org/stable/c/cd7eb8f83fcf258f71e293f7fc52a70be8ed0128
Modified: 2024-11-21
CVE-2024-36893
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.
- https://git.kernel.org/stable/c/2a07e6f0ad8a6e504a3912cfe8dc859b7d0740a5
- https://git.kernel.org/stable/c/789326cafbd1f67f424436b6bc8bdb887a364637
- https://git.kernel.org/stable/c/ae11f04b452b5205536e1c02d31f8045eba249dd
- https://git.kernel.org/stable/c/d56d2ca03cc22123fd7626967d096d8661324e57
- https://git.kernel.org/stable/c/fc2b655cb6dd2b381f1f284989721002e39b6b77
- https://git.kernel.org/stable/c/789326cafbd1f67f424436b6bc8bdb887a364637
- https://git.kernel.org/stable/c/ae11f04b452b5205536e1c02d31f8045eba249dd
- https://git.kernel.org/stable/c/d56d2ca03cc22123fd7626967d096d8661324e57
- https://git.kernel.org/stable/c/fc2b655cb6dd2b381f1f284989721002e39b6b77
Modified: 2025-04-01
CVE-2024-36896
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.
- https://git.kernel.org/stable/c/5f1d68ef5ddac27c6b997adccd1c339cef1e6848
- https://git.kernel.org/stable/c/6119ef6517ce501fc548154691abdaf1f954a277
- https://git.kernel.org/stable/c/63533549ff53d24daf47c443dbd43c308afc3434
- https://git.kernel.org/stable/c/a4b46d450c49f32e9d4247b421e58083fde304ce
- https://git.kernel.org/stable/c/5f1d68ef5ddac27c6b997adccd1c339cef1e6848
- https://git.kernel.org/stable/c/6119ef6517ce501fc548154691abdaf1f954a277
- https://git.kernel.org/stable/c/63533549ff53d24daf47c443dbd43c308afc3434
- https://git.kernel.org/stable/c/a4b46d450c49f32e9d4247b421e58083fde304ce
Modified: 2024-11-21
CVE-2024-36897
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.
- https://git.kernel.org/stable/c/02f5300f6827206f6e48a77f51e6264993695e5c
- https://git.kernel.org/stable/c/3c7013a87124bab54216d9b99f77e8b6de6fbc1a
- https://git.kernel.org/stable/c/7e3030774431eb093165a31baff040d35446fb8b
- https://git.kernel.org/stable/c/9a35d205f466501dcfe5625ca313d944d0ac2d60
- https://git.kernel.org/stable/c/c2797ec16d9072327e7578d09ee05bcab52fffd0
- https://git.kernel.org/stable/c/02f5300f6827206f6e48a77f51e6264993695e5c
- https://git.kernel.org/stable/c/3c7013a87124bab54216d9b99f77e8b6de6fbc1a
- https://git.kernel.org/stable/c/7e3030774431eb093165a31baff040d35446fb8b
- https://git.kernel.org/stable/c/9a35d205f466501dcfe5625ca313d944d0ac2d60
- https://git.kernel.org/stable/c/c2797ec16d9072327e7578d09ee05bcab52fffd0
Modified: 2026-04-23
CVE-2024-36898
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.
- https://git.kernel.org/stable/c/1a51e24404d77bb3307c1e39eee0d8e86febb1a5
- https://git.kernel.org/stable/c/883e4bbf06eb5fb7482679e4edb201093e9f55a2
- https://git.kernel.org/stable/c/bd7139a70ee8d8ea872b223e043730cf6f5e2b0e
- https://git.kernel.org/stable/c/c87cc32bc48b187067e089b15ab7a6a7eed5767d
- https://git.kernel.org/stable/c/ee0166b637a5e376118e9659e5b4148080f1d27e
- https://git.kernel.org/stable/c/1a51e24404d77bb3307c1e39eee0d8e86febb1a5
- https://git.kernel.org/stable/c/883e4bbf06eb5fb7482679e4edb201093e9f55a2
- https://git.kernel.org/stable/c/bd7139a70ee8d8ea872b223e043730cf6f5e2b0e
- https://git.kernel.org/stable/c/ee0166b637a5e376118e9659e5b4148080f1d27e
Modified: 2025-09-30
CVE-2024-36900
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.
- https://git.kernel.org/stable/c/35d92abfbad88cf947c010baf34b075e40566095
- https://git.kernel.org/stable/c/5c623fe0534806b627054da09b6f51b7b2f7b9cd
- https://git.kernel.org/stable/c/72ede790f5a03c3957487400a1b72ebce293a2e7
- https://git.kernel.org/stable/c/c98bc78ce0909ccc92005e2cb6609ec6c7942f69
- https://git.kernel.org/stable/c/35d92abfbad88cf947c010baf34b075e40566095
- https://git.kernel.org/stable/c/5c623fe0534806b627054da09b6f51b7b2f7b9cd
- https://git.kernel.org/stable/c/72ede790f5a03c3957487400a1b72ebce293a2e7
- https://git.kernel.org/stable/c/c98bc78ce0909ccc92005e2cb6609ec6c7942f69
Modified: 2024-11-21
CVE-2024-36901
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:
- https://git.kernel.org/stable/c/2272e2db38f2e85929278146d7c770f22f528579
- https://git.kernel.org/stable/c/4db783d68b9b39a411a96096c10828ff5dfada7a
- https://git.kernel.org/stable/c/55f7eb4001ef2a3b48cf039cf263f9ed0ec5a488
- https://git.kernel.org/stable/c/9df3b2474a627994433a87cbf325a562555b17de
- https://git.kernel.org/stable/c/e31b25cc2066d3f2b6c38579253882008d4469b0
- https://git.kernel.org/stable/c/ea0cb87402f774b0e1214ffba0f57028b27cf155
- https://git.kernel.org/stable/c/2272e2db38f2e85929278146d7c770f22f528579
- https://git.kernel.org/stable/c/4db783d68b9b39a411a96096c10828ff5dfada7a
- https://git.kernel.org/stable/c/55f7eb4001ef2a3b48cf039cf263f9ed0ec5a488
- https://git.kernel.org/stable/c/9df3b2474a627994433a87cbf325a562555b17de
- https://git.kernel.org/stable/c/e31b25cc2066d3f2b6c38579253882008d4469b0
- https://git.kernel.org/stable/c/ea0cb87402f774b0e1214ffba0f57028b27cf155
Modified: 2024-11-21
CVE-2024-36902
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:
- https://git.kernel.org/stable/c/1876881c9a49613b5249fb400cbf53412d90cb09
- https://git.kernel.org/stable/c/35297fc68de36826087e976f86a5b1f94fd0bf95
- https://git.kernel.org/stable/c/4a5a573387da6a6b23a4cc62147453ff1bc32afa
- https://git.kernel.org/stable/c/674c951ab8a23f7aff9b4c3f2f865901bc76a290
- https://git.kernel.org/stable/c/7e3242c139c38e60844638e394c2877b16b396b0
- https://git.kernel.org/stable/c/8745a8d74ba17dafe72b6ab461fa6c007d879747
- https://git.kernel.org/stable/c/d101291b2681e5ab938554e3e323f7a7ee33e3aa
- https://git.kernel.org/stable/c/ddec23f206a944c73bcc2724358b85388837daff
- https://git.kernel.org/stable/c/1876881c9a49613b5249fb400cbf53412d90cb09
- https://git.kernel.org/stable/c/35297fc68de36826087e976f86a5b1f94fd0bf95
- https://git.kernel.org/stable/c/4a5a573387da6a6b23a4cc62147453ff1bc32afa
- https://git.kernel.org/stable/c/674c951ab8a23f7aff9b4c3f2f865901bc76a290
- https://git.kernel.org/stable/c/7e3242c139c38e60844638e394c2877b16b396b0
- https://git.kernel.org/stable/c/8745a8d74ba17dafe72b6ab461fa6c007d879747
- https://git.kernel.org/stable/c/d101291b2681e5ab938554e3e323f7a7ee33e3aa
- https://git.kernel.org/stable/c/ddec23f206a944c73bcc2724358b85388837daff
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://security.netapp.com/advisory/ntap-20240926-0002/
Modified: 2026-01-22
CVE-2024-36904
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:
- https://git.kernel.org/stable/c/13ed7cdf079686ccd3618335205700c03f6fb446
- https://git.kernel.org/stable/c/1796ca9c6f5bd50554214053af5f47d112818ee3
- https://git.kernel.org/stable/c/1d9cf07810c30ef7948879567d10fd1f01121d34
- https://git.kernel.org/stable/c/27b0284d8be182a81feb65581ab6a724dfd596e8
- https://git.kernel.org/stable/c/517e32ea0a8c72202d0d8aa8df50a7cd3d6fdefc
- https://git.kernel.org/stable/c/6e48faad92be13166184d21506e4e54c79c13adc
- https://git.kernel.org/stable/c/84546cc1aeeb4df3e444b18a4293c9823f974be9
- https://git.kernel.org/stable/c/f2db7230f73a80dbb179deab78f88a7947f0ab7e
- https://git.kernel.org/stable/c/13ed7cdf079686ccd3618335205700c03f6fb446
- https://git.kernel.org/stable/c/1796ca9c6f5bd50554214053af5f47d112818ee3
- https://git.kernel.org/stable/c/1d9cf07810c30ef7948879567d10fd1f01121d34
- https://git.kernel.org/stable/c/27b0284d8be182a81feb65581ab6a724dfd596e8
- https://git.kernel.org/stable/c/517e32ea0a8c72202d0d8aa8df50a7cd3d6fdefc
- https://git.kernel.org/stable/c/6e48faad92be13166184d21506e4e54c79c13adc
- https://git.kernel.org/stable/c/84546cc1aeeb4df3e444b18a4293c9823f974be9
- https://git.kernel.org/stable/c/f2db7230f73a80dbb179deab78f88a7947f0ab7e
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://security.netapp.com/advisory/ntap-20240905-0004/
Modified: 2026-01-22
CVE-2024-36905
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:
- https://git.kernel.org/stable/c/2552c9d9440f8e7a2ed0660911ff00f25b90a0a4
- https://git.kernel.org/stable/c/34e41a031fd7523bf1cd00a2adca2370aebea270
- https://git.kernel.org/stable/c/3fe4ef0568a48369b1891395d13ac593b1ba41b1
- https://git.kernel.org/stable/c/413c33b9f3bc36fdf719690a78824db9f88a9485
- https://git.kernel.org/stable/c/94062790aedb505bdda209b10bea47b294d6394f
- https://git.kernel.org/stable/c/cbf232ba11bc86a5281b4f00e1151349ef4d45cf
- https://git.kernel.org/stable/c/ed5e279b69e007ce6c0fe82a5a534c1b19783214
- https://git.kernel.org/stable/c/f47d0d32fa94e815fdd78b8b88684873e67939f4
- https://www.openwall.com/lists/oss-security/2024/10/29/1
- http://www.openwall.com/lists/oss-security/2024/10/29/1
- http://www.openwall.com/lists/oss-security/2024/10/30/1
- http://www.openwall.com/lists/oss-security/2024/11/12/4
- http://www.openwall.com/lists/oss-security/2024/11/12/5
- http://www.openwall.com/lists/oss-security/2024/11/12/6
- https://git.kernel.org/stable/c/2552c9d9440f8e7a2ed0660911ff00f25b90a0a4
- https://git.kernel.org/stable/c/34e41a031fd7523bf1cd00a2adca2370aebea270
- https://git.kernel.org/stable/c/3fe4ef0568a48369b1891395d13ac593b1ba41b1
- https://git.kernel.org/stable/c/413c33b9f3bc36fdf719690a78824db9f88a9485
- https://git.kernel.org/stable/c/94062790aedb505bdda209b10bea47b294d6394f
- https://git.kernel.org/stable/c/cbf232ba11bc86a5281b4f00e1151349ef4d45cf
- https://git.kernel.org/stable/c/ed5e279b69e007ce6c0fe82a5a534c1b19783214
- https://git.kernel.org/stable/c/f47d0d32fa94e815fdd78b8b88684873e67939f4
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://security.netapp.com/advisory/ntap-20240905-0005/
- https://access.redhat.com/security/cve/cve-2024-36905
- https://alas.aws.amazon.com/cve/html/CVE-2024-36905.html
- https://github.com/cisagov/vulnrichment/issues/130
- https://www.openwall.com/lists/oss-security/2024/11/12/4
Modified: 2025-09-17
CVE-2024-36906
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")
- https://git.kernel.org/stable/c/20ac71bee028ffbae4fc14ed679b23b4d3e95726
- https://git.kernel.org/stable/c/ad702338fe423cb1e79745787090317256a98dab
- https://git.kernel.org/stable/c/b26f353786d365e658cebc9a9ace88e04fc2325e
- https://git.kernel.org/stable/c/c4238686f9093b98bd6245a348bcf059cdce23af
- https://git.kernel.org/stable/c/ee0ce7573e5083031960faf602c9db693ab5b477
- https://git.kernel.org/stable/c/20ac71bee028ffbae4fc14ed679b23b4d3e95726
- https://git.kernel.org/stable/c/ad702338fe423cb1e79745787090317256a98dab
- https://git.kernel.org/stable/c/b26f353786d365e658cebc9a9ace88e04fc2325e
- https://git.kernel.org/stable/c/c4238686f9093b98bd6245a348bcf059cdce23af
- https://git.kernel.org/stable/c/ee0ce7573e5083031960faf602c9db693ab5b477
Modified: 2025-09-30
CVE-2024-36909
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.
- https://git.kernel.org/stable/c/2f622008bf784a9f5dd17baa19223cc2ac30a039
- https://git.kernel.org/stable/c/30d18df6567be09c1433e81993e35e3da573ac48
- https://git.kernel.org/stable/c/82f9e213b124a7d2bb5b16ea35d570260ef467e0
- https://git.kernel.org/stable/c/a9212a4e2963a7fbe3864ba33dc551d4ad8d0abb
- https://git.kernel.org/stable/c/2f622008bf784a9f5dd17baa19223cc2ac30a039
- https://git.kernel.org/stable/c/30d18df6567be09c1433e81993e35e3da573ac48
- https://git.kernel.org/stable/c/82f9e213b124a7d2bb5b16ea35d570260ef467e0
- https://git.kernel.org/stable/c/a9212a4e2963a7fbe3864ba33dc551d4ad8d0abb
Modified: 2025-04-01
CVE-2024-36910
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.
- https://git.kernel.org/stable/c/3d788b2fbe6a1a1a9e3db09742b90809d51638b7
- https://git.kernel.org/stable/c/6466a0f6d235c8a18c602cb587160d7e49876db9
- https://git.kernel.org/stable/c/dabf12bf994318d939f70d47cfda30e47abb2c54
- https://git.kernel.org/stable/c/fe2c58602354fbd60680dc42ac3a0b772cda7d23
- https://git.kernel.org/stable/c/3d788b2fbe6a1a1a9e3db09742b90809d51638b7
- https://git.kernel.org/stable/c/6466a0f6d235c8a18c602cb587160d7e49876db9
- https://git.kernel.org/stable/c/dabf12bf994318d939f70d47cfda30e47abb2c54
- https://git.kernel.org/stable/c/fe2c58602354fbd60680dc42ac3a0b772cda7d23
Modified: 2025-11-18
CVE-2024-36912
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.
- https://git.kernel.org/stable/c/1999644d95194d4a58d3e80ad04ce19220a01a81
- https://git.kernel.org/stable/c/211f514ebf1ef5de37b1cf6df9d28a56cfd242ca
- https://git.kernel.org/stable/c/8e62341f5c45b27519b7d193bcc32ada416ad9d8
- https://git.kernel.org/stable/c/bfae56be077ba14311509e70706a13458f87ea99
- https://git.kernel.org/stable/c/1999644d95194d4a58d3e80ad04ce19220a01a81
- https://git.kernel.org/stable/c/211f514ebf1ef5de37b1cf6df9d28a56cfd242ca
- https://git.kernel.org/stable/c/8e62341f5c45b27519b7d193bcc32ada416ad9d8
- https://git.kernel.org/stable/c/bfae56be077ba14311509e70706a13458f87ea99
Modified: 2026-01-22
CVE-2024-36916
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:
- https://git.kernel.org/stable/c/488dc6808cb8369685f18cee81e88e7052ac153b
- https://git.kernel.org/stable/c/62accf6c1d7b433752cb3591bba8967b7a801ad5
- https://git.kernel.org/stable/c/844fc023e9f14a4fb1de5ae1eaefafd6d69c5fa1
- https://git.kernel.org/stable/c/beaa51b36012fad5a4d3c18b88a617aea7a9b96d
- https://git.kernel.org/stable/c/ce0e99cae00e3131872936713b7f55eefd53ab86
- https://git.kernel.org/stable/c/f6add0a6f78dc6360b822ca4b6f9f2f14174c8ca
- https://git.kernel.org/stable/c/488dc6808cb8369685f18cee81e88e7052ac153b
- https://git.kernel.org/stable/c/62accf6c1d7b433752cb3591bba8967b7a801ad5
- https://git.kernel.org/stable/c/844fc023e9f14a4fb1de5ae1eaefafd6d69c5fa1
- https://git.kernel.org/stable/c/beaa51b36012fad5a4d3c18b88a617aea7a9b96d
- https://git.kernel.org/stable/c/ce0e99cae00e3131872936713b7f55eefd53ab86
- https://git.kernel.org/stable/c/f6add0a6f78dc6360b822ca4b6f9f2f14174c8ca
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
- https://security.netapp.com/advisory/ntap-20240905-0006/
Modified: 2025-09-17
CVE-2024-36917
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.
- https://git.kernel.org/stable/c/22d24a544b0d49bbcbd61c8c0eaf77d3c9297155
- https://git.kernel.org/stable/c/507d526a98c355e6f3fb2c47aacad44a69784bee
- https://git.kernel.org/stable/c/8a26198186e97ee5fc4b42fde82629cff8c75cd6
- https://git.kernel.org/stable/c/e1d38cde2b7b0fbd1c48082e7a98c37d750af59b
- https://git.kernel.org/stable/c/22d24a544b0d49bbcbd61c8c0eaf77d3c9297155
- https://git.kernel.org/stable/c/507d526a98c355e6f3fb2c47aacad44a69784bee
- https://git.kernel.org/stable/c/8a26198186e97ee5fc4b42fde82629cff8c75cd6
- https://git.kernel.org/stable/c/e1d38cde2b7b0fbd1c48082e7a98c37d750af59b
Modified: 2025-09-17
CVE-2024-36918
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.
- https://git.kernel.org/stable/c/608e13706c8b6c658a0646f09ebced74ec367f7c
- https://git.kernel.org/stable/c/a8d89feba7e54e691ca7c4efc2a6264fa83f3687
- https://git.kernel.org/stable/c/c418afb9bf23e2f2b76cb819601e4a5d9dbab42d
- https://git.kernel.org/stable/c/fa6995eeb62e74b5a1480c73fb7b420c270784d3
- https://git.kernel.org/stable/c/608e13706c8b6c658a0646f09ebced74ec367f7c
- https://git.kernel.org/stable/c/a8d89feba7e54e691ca7c4efc2a6264fa83f3687
- https://git.kernel.org/stable/c/c418afb9bf23e2f2b76cb819601e4a5d9dbab42d
- https://git.kernel.org/stable/c/fa6995eeb62e74b5a1480c73fb7b420c270784d3
Modified: 2026-01-22
CVE-2024-36919
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 ]---
- https://git.kernel.org/stable/c/1150606d47d711d5bfdf329a1a96ed7027085936
- https://git.kernel.org/stable/c/468f3e3c15076338367b0945b041105b67cf31e3
- https://git.kernel.org/stable/c/93aa5ccc44781bdfef1bf0bc4c2c292d45251312
- https://git.kernel.org/stable/c/acd370c1fb86b7302c1cbb354a7c1cd9953768eb
- https://git.kernel.org/stable/c/ad498539dda0816aadef384ec117bfea304c75c3
- https://git.kernel.org/stable/c/c214ed2a4dda35b308b0b28eed804d7ae66401f9
- https://git.kernel.org/stable/c/c885ab23206b1f1ba0731ffe7c9455c6a91db256
- https://git.kernel.org/stable/c/ea50941cd8c9f0b12f38b73d3b1bfeca660dd342
- https://git.kernel.org/stable/c/1150606d47d711d5bfdf329a1a96ed7027085936
- https://git.kernel.org/stable/c/468f3e3c15076338367b0945b041105b67cf31e3
- https://git.kernel.org/stable/c/93aa5ccc44781bdfef1bf0bc4c2c292d45251312
- https://git.kernel.org/stable/c/acd370c1fb86b7302c1cbb354a7c1cd9953768eb
- https://git.kernel.org/stable/c/ad498539dda0816aadef384ec117bfea304c75c3
- https://git.kernel.org/stable/c/c214ed2a4dda35b308b0b28eed804d7ae66401f9
- https://git.kernel.org/stable/c/c885ab23206b1f1ba0731ffe7c9455c6a91db256
- https://git.kernel.org/stable/c/ea50941cd8c9f0b12f38b73d3b1bfeca660dd342
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://security.netapp.com/advisory/ntap-20240905-0009/
Modified: 2025-10-01
CVE-2024-36920
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.
- https://git.kernel.org/stable/c/429846b4b6ce9853e0d803a2357bb2e55083adf0
- https://git.kernel.org/stable/c/4d2772324f43cf5674ac3dbe3f74a7e656396716
- https://git.kernel.org/stable/c/5f0266044dc611563539705bff0b3e1545fbb6aa
- https://git.kernel.org/stable/c/f09318244c6cafd10aca741b9c01e0a2c362d43a
- https://git.kernel.org/stable/c/429846b4b6ce9853e0d803a2357bb2e55083adf0
- https://git.kernel.org/stable/c/4d2772324f43cf5674ac3dbe3f74a7e656396716
- https://git.kernel.org/stable/c/5f0266044dc611563539705bff0b3e1545fbb6aa
- https://git.kernel.org/stable/c/f09318244c6cafd10aca741b9c01e0a2c362d43a
Modified: 2025-01-10
CVE-2024-36924
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.
- https://git.kernel.org/stable/c/6503c39398506cadda9f4c81695a9655ca5fb4fd
- https://git.kernel.org/stable/c/ded20192dff31c91cef2a04f7e20e60e9bb887d3
- https://git.kernel.org/stable/c/e8bf2c05e8ad68e90f9d5889a9e4ef3f6fe00683
- https://git.kernel.org/stable/c/ee833d7e62de2b84ed1332d501b67f12e7e5678f
- https://git.kernel.org/stable/c/6503c39398506cadda9f4c81695a9655ca5fb4fd
- https://git.kernel.org/stable/c/ded20192dff31c91cef2a04f7e20e60e9bb887d3
- https://git.kernel.org/stable/c/e8bf2c05e8ad68e90f9d5889a9e4ef3f6fe00683
- https://git.kernel.org/stable/c/ee833d7e62de2b84ed1332d501b67f12e7e5678f
Modified: 2024-11-21
CVE-2024-36926
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
- https://git.kernel.org/stable/c/2bed905a72485a2b79a001bd7e66c750942d2155
- https://git.kernel.org/stable/c/49a940dbdc3107fecd5e6d3063dc07128177e058
- https://git.kernel.org/stable/c/7fb5793c53f8c024e3eae9f0d44eb659aed833c4
- https://git.kernel.org/stable/c/802b13b79ab1fef66c6852fc745cf197dca0cb15
- https://git.kernel.org/stable/c/2bed905a72485a2b79a001bd7e66c750942d2155
- https://git.kernel.org/stable/c/49a940dbdc3107fecd5e6d3063dc07128177e058
- https://git.kernel.org/stable/c/7fb5793c53f8c024e3eae9f0d44eb659aed833c4
- https://git.kernel.org/stable/c/802b13b79ab1fef66c6852fc745cf197dca0cb15
Modified: 2025-04-01
CVE-2024-36928
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---
- https://git.kernel.org/stable/c/10cb803aff3b11fe0bd5f274fc1c231a43e88df6
- https://git.kernel.org/stable/c/8792b557eb50b986f2496156d486d0c7c85a1524
- https://git.kernel.org/stable/c/8a2e4d37afb8500b276e5ee903dee06f50ab0494
- https://git.kernel.org/stable/c/e28dd1e1bf3ebb52cdb877fb359e8978a51576e3
- https://git.kernel.org/stable/c/eae0aec245712c52a3ce9c05575b541a9eef5282
- https://git.kernel.org/stable/c/10cb803aff3b11fe0bd5f274fc1c231a43e88df6
- https://git.kernel.org/stable/c/8792b557eb50b986f2496156d486d0c7c85a1524
- https://git.kernel.org/stable/c/8a2e4d37afb8500b276e5ee903dee06f50ab0494
- https://git.kernel.org/stable/c/e28dd1e1bf3ebb52cdb877fb359e8978a51576e3
- https://git.kernel.org/stable/c/eae0aec245712c52a3ce9c05575b541a9eef5282
Modified: 2026-01-22
CVE-2024-36929
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.
- https://git.kernel.org/stable/c/989bf6fd1e1d058e73a364dce1a0c53d33373f62
- https://git.kernel.org/stable/c/aea5e2669c2863fdd8679c40ee310b3bcaa85aec
- https://git.kernel.org/stable/c/c7af99cc21923a9650533c9d77265c8dd683a533
- https://git.kernel.org/stable/c/cfe34d86ef9765c388f145039006bb79b6c81ac6
- https://git.kernel.org/stable/c/d091e579b864fa790dd6a0cd537a22c383126681
- https://git.kernel.org/stable/c/faa83a7797f06cefed86731ba4baa3b4dfdc06c1
- https://git.kernel.org/stable/c/989bf6fd1e1d058e73a364dce1a0c53d33373f62
- https://git.kernel.org/stable/c/aea5e2669c2863fdd8679c40ee310b3bcaa85aec
- https://git.kernel.org/stable/c/c7af99cc21923a9650533c9d77265c8dd683a533
- https://git.kernel.org/stable/c/cfe34d86ef9765c388f145039006bb79b6c81ac6
- https://git.kernel.org/stable/c/d091e579b864fa790dd6a0cd537a22c383126681
- https://git.kernel.org/stable/c/faa83a7797f06cefed86731ba4baa3b4dfdc06c1
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
- https://security.netapp.com/advisory/ntap-20240905-0010/
Modified: 2024-11-21
CVE-2024-36930
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.
- https://git.kernel.org/stable/c/2070d008cc08bff50a58f0f4d30f12d3ebf94c00
- https://git.kernel.org/stable/c/4756fa529b2f12b7cb8f21fe229b0f6f47190829
- https://git.kernel.org/stable/c/a30659f1576d2c8e62e7426232bb18b885fd951a
- https://git.kernel.org/stable/c/e005d6754e3e440257006795b687c4ad8733b493
- https://git.kernel.org/stable/c/2070d008cc08bff50a58f0f4d30f12d3ebf94c00
- https://git.kernel.org/stable/c/4756fa529b2f12b7cb8f21fe229b0f6f47190829
- https://git.kernel.org/stable/c/a30659f1576d2c8e62e7426232bb18b885fd951a
- https://git.kernel.org/stable/c/e005d6754e3e440257006795b687c4ad8733b493
Modified: 2025-01-15
CVE-2024-36931
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.
- https://git.kernel.org/stable/c/06759ebaf75c19c87b2453a5e130e9e61e9b5d65
- https://git.kernel.org/stable/c/10452edd175fcc4fd0f5ac782ed2a002e3e5d65c
- https://git.kernel.org/stable/c/84b38f48836662c4bfae646c014f4e981e16a2b2
- https://git.kernel.org/stable/c/c9d48ce163305595ae20aee27774192476d5e6a5
- https://git.kernel.org/stable/c/da7c622cddd4fe36be69ca61e8c42e43cde94784
- https://git.kernel.org/stable/c/06759ebaf75c19c87b2453a5e130e9e61e9b5d65
- https://git.kernel.org/stable/c/10452edd175fcc4fd0f5ac782ed2a002e3e5d65c
- https://git.kernel.org/stable/c/84b38f48836662c4bfae646c014f4e981e16a2b2
- https://git.kernel.org/stable/c/c9d48ce163305595ae20aee27774192476d5e6a5
- https://git.kernel.org/stable/c/da7c622cddd4fe36be69ca61e8c42e43cde94784
Modified: 2026-01-22
CVE-2024-36933
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---
- https://git.kernel.org/stable/c/29a07f2ee4d273760c2acbfc756e29eccd82470a
- https://git.kernel.org/stable/c/37ed6f244ec5bda2e90b085084e322ea55d0aaa2
- https://git.kernel.org/stable/c/46134031c20fd313d03b90169d64b2e05ca6b65c
- https://git.kernel.org/stable/c/4b911a9690d72641879ea6d13cce1de31d346d79
- https://git.kernel.org/stable/c/5a4603fbc285752d19e4b415466db18ef3617e4a
- https://git.kernel.org/stable/c/696d18bb59727a2e0526c0802a812620be1c9340
- https://git.kernel.org/stable/c/a7c2c3c1caabcb4a3d6c47284c397507aaf54fe9
- https://git.kernel.org/stable/c/bbccf0caef2fa917d6d0692385a06ce3c262a216
- https://git.kernel.org/stable/c/29a07f2ee4d273760c2acbfc756e29eccd82470a
- https://git.kernel.org/stable/c/37ed6f244ec5bda2e90b085084e322ea55d0aaa2
- https://git.kernel.org/stable/c/46134031c20fd313d03b90169d64b2e05ca6b65c
- https://git.kernel.org/stable/c/4b911a9690d72641879ea6d13cce1de31d346d79
- https://git.kernel.org/stable/c/5a4603fbc285752d19e4b415466db18ef3617e4a
- https://git.kernel.org/stable/c/696d18bb59727a2e0526c0802a812620be1c9340
- https://git.kernel.org/stable/c/a7c2c3c1caabcb4a3d6c47284c397507aaf54fe9
- https://git.kernel.org/stable/c/bbccf0caef2fa917d6d0692385a06ce3c262a216
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://security.netapp.com/advisory/ntap-20240912-0006/
Modified: 2026-01-22
CVE-2024-36934
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.
- https://git.kernel.org/stable/c/06cb37e2ba6441888f24566a997481d4197b4e32
- https://git.kernel.org/stable/c/0f560240b4cc25d3de527deb257cdf072c0102a9
- https://git.kernel.org/stable/c/1518b2b498a0109eb6b15755169d3b6607356b35
- https://git.kernel.org/stable/c/6f0f19b79c085cc891c418b768f26f7004bd51a4
- https://git.kernel.org/stable/c/80578ec10335bc15ac35fd1703c22aab34e39fdd
- https://git.kernel.org/stable/c/8c34096c7fdf272fd4c0c37fe411cd2e3ed0ee9f
- https://git.kernel.org/stable/c/bd502ba81cd1d515deddad7dbc6b812b14b97147
- https://git.kernel.org/stable/c/e19478763154674c084defc62ae0d64d79657f91
- https://git.kernel.org/stable/c/06cb37e2ba6441888f24566a997481d4197b4e32
- https://git.kernel.org/stable/c/0f560240b4cc25d3de527deb257cdf072c0102a9
- https://git.kernel.org/stable/c/1518b2b498a0109eb6b15755169d3b6607356b35
- https://git.kernel.org/stable/c/6f0f19b79c085cc891c418b768f26f7004bd51a4
- https://git.kernel.org/stable/c/80578ec10335bc15ac35fd1703c22aab34e39fdd
- https://git.kernel.org/stable/c/8c34096c7fdf272fd4c0c37fe411cd2e3ed0ee9f
- https://git.kernel.org/stable/c/bd502ba81cd1d515deddad7dbc6b812b14b97147
- https://git.kernel.org/stable/c/e19478763154674c084defc62ae0d64d79657f91
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://security.netapp.com/advisory/ntap-20240912-0007/
Modified: 2025-09-17
CVE-2024-36937
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.
- https://git.kernel.org/stable/c/12481f30128fbebc2eeb55eb2d56390fdfa30c5e
- https://git.kernel.org/stable/c/272bfb019f3cc018f654b992115774e77b4f3ffc
- https://git.kernel.org/stable/c/5bcf0dcbf9066348058b88a510c57f70f384c92c
- https://git.kernel.org/stable/c/6fd81f9d333e7b3532036577b1beb74ba1323553
- https://git.kernel.org/stable/c/e22e25820fa04ea5eaac4ef7ee200e9923f466a4
- https://git.kernel.org/stable/c/12481f30128fbebc2eeb55eb2d56390fdfa30c5e
- https://git.kernel.org/stable/c/272bfb019f3cc018f654b992115774e77b4f3ffc
- https://git.kernel.org/stable/c/5bcf0dcbf9066348058b88a510c57f70f384c92c
- https://git.kernel.org/stable/c/6fd81f9d333e7b3532036577b1beb74ba1323553
- https://git.kernel.org/stable/c/e22e25820fa04ea5eaac4ef7ee200e9923f466a4
Modified: 2024-11-21
CVE-2024-36938
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.
- https://git.kernel.org/stable/c/39dc9e1442385d6e9be0b6491ee488dddd55ae27
- https://git.kernel.org/stable/c/5965bc7535fb87510b724e5465ccc1a1cf00916d
- https://git.kernel.org/stable/c/6648e613226e18897231ab5e42ffc29e63fa3365
- https://git.kernel.org/stable/c/772d5729b5ff0df0d37b32db600ce635b2172f80
- https://git.kernel.org/stable/c/b397a0ab8582c533ec0c6b732392f141fc364f87
- https://git.kernel.org/stable/c/c0809c128dad4c3413818384eb06a341633db973
- https://git.kernel.org/stable/c/39dc9e1442385d6e9be0b6491ee488dddd55ae27
- https://git.kernel.org/stable/c/5965bc7535fb87510b724e5465ccc1a1cf00916d
- https://git.kernel.org/stable/c/6648e613226e18897231ab5e42ffc29e63fa3365
- https://git.kernel.org/stable/c/772d5729b5ff0df0d37b32db600ce635b2172f80
- https://git.kernel.org/stable/c/b397a0ab8582c533ec0c6b732392f141fc364f87
- https://git.kernel.org/stable/c/c0809c128dad4c3413818384eb06a341633db973
Modified: 2025-12-17
CVE-2024-36939
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:
- https://git.kernel.org/stable/c/24457f1be29f1e7042e50a7749f5c2dde8c433c8
- https://git.kernel.org/stable/c/8a1f89c98dcc542dd6d287e573523714702e0f9c
- https://git.kernel.org/stable/c/8ae63bd858691bee0e2a92571f2fbb36a4d86d65
- https://git.kernel.org/stable/c/9909dde2e53a19585212c32fe3eda482b5faaaa3
- https://git.kernel.org/stable/c/b33ca18c3a1190208dfd569c4fa8a2f93084709f
- https://git.kernel.org/stable/c/d4891d817350c67392d4731536945f3809a2a0ba
- https://git.kernel.org/stable/c/ea6ce93327bd2c8a0c6cf6f2f0e800f3b778f021
- https://git.kernel.org/stable/c/24457f1be29f1e7042e50a7749f5c2dde8c433c8
- https://git.kernel.org/stable/c/8a1f89c98dcc542dd6d287e573523714702e0f9c
- https://git.kernel.org/stable/c/8ae63bd858691bee0e2a92571f2fbb36a4d86d65
- https://git.kernel.org/stable/c/9909dde2e53a19585212c32fe3eda482b5faaaa3
- https://git.kernel.org/stable/c/b33ca18c3a1190208dfd569c4fa8a2f93084709f
- https://git.kernel.org/stable/c/d4891d817350c67392d4731536945f3809a2a0ba
- https://git.kernel.org/stable/c/ea6ce93327bd2c8a0c6cf6f2f0e800f3b778f021
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
Modified: 2025-01-10
CVE-2024-36940
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.
- https://git.kernel.org/stable/c/288bc4aa75f150d6f1ee82dd43c6da1b438b6068
- https://git.kernel.org/stable/c/41f88ef8ba387a12f4a2b8c400b6c9e8e54b2cca
- https://git.kernel.org/stable/c/5038a66dad0199de60e5671603ea6623eb9e5c79
- https://git.kernel.org/stable/c/558c8039fdf596a584a92c171cbf3298919c448c
- https://git.kernel.org/stable/c/735f4c6b6771eafe336404c157ca683ad72a040d
- https://git.kernel.org/stable/c/ac7d65795827dc0cf7662384ed27caf4066bd72e
- https://git.kernel.org/stable/c/cdaa171473d98962ae86f2a663d398fda2fbeefd
- https://git.kernel.org/stable/c/f9f1e321d53e4c5b666b66e5b43da29841fb55ba
- https://git.kernel.org/stable/c/288bc4aa75f150d6f1ee82dd43c6da1b438b6068
- https://git.kernel.org/stable/c/41f88ef8ba387a12f4a2b8c400b6c9e8e54b2cca
- https://git.kernel.org/stable/c/5038a66dad0199de60e5671603ea6623eb9e5c79
- https://git.kernel.org/stable/c/558c8039fdf596a584a92c171cbf3298919c448c
- https://git.kernel.org/stable/c/735f4c6b6771eafe336404c157ca683ad72a040d
- https://git.kernel.org/stable/c/ac7d65795827dc0cf7662384ed27caf4066bd72e
- https://git.kernel.org/stable/c/cdaa171473d98962ae86f2a663d398fda2fbeefd
- https://git.kernel.org/stable/c/f9f1e321d53e4c5b666b66e5b43da29841fb55ba
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-05-20
CVE-2024-36941
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.
- https://git.kernel.org/stable/c/244822c09b4f9aedfb5977f03c0deeb39da8ec7d
- https://git.kernel.org/stable/c/327382dc0f16b268950b96e0052595efd80f7b0a
- https://git.kernel.org/stable/c/5a730a161ac2290d46d49be76b2b1aee8d2eb307
- https://git.kernel.org/stable/c/801ea33ae82d6a9d954074fbcf8ea9d18f1543a7
- https://git.kernel.org/stable/c/97792d0611ae2e6fe3ccefb0a94a1d802317c457
- https://git.kernel.org/stable/c/ad12c74e953b68ad85c78adc6408ed8435c64af4
- https://git.kernel.org/stable/c/b0db4caa10f2e4e811cf88744fbf0d074b67ec1f
- https://git.kernel.org/stable/c/f92772a642485394db5c9a17bd0ee73fc6902383
- https://git.kernel.org/stable/c/244822c09b4f9aedfb5977f03c0deeb39da8ec7d
- https://git.kernel.org/stable/c/327382dc0f16b268950b96e0052595efd80f7b0a
- https://git.kernel.org/stable/c/5a730a161ac2290d46d49be76b2b1aee8d2eb307
- https://git.kernel.org/stable/c/801ea33ae82d6a9d954074fbcf8ea9d18f1543a7
- https://git.kernel.org/stable/c/97792d0611ae2e6fe3ccefb0a94a1d802317c457
- https://git.kernel.org/stable/c/ad12c74e953b68ad85c78adc6408ed8435c64af4
- https://git.kernel.org/stable/c/b0db4caa10f2e4e811cf88744fbf0d074b67ec1f
- https://git.kernel.org/stable/c/f92772a642485394db5c9a17bd0ee73fc6902383
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-04-01
CVE-2024-36944
In the Linux kernel, the following vulnerability has been resolved: Reapply "drm/qxl: simplify qxl_fence_wait" This reverts commit 07ed11afb68d94eadd4ffc082b97c2331307c5ea. Stephen Rostedt reports: "I went to run my tests on my VMs and the tests hung on boot up. Unfortunately, the most I ever got out was: [ 93.607888] Testing event system initcall: OK [ 93.667730] Running tests on all trace events: [ 93.669757] Testing all events: OK [ 95.631064] ------------[ cut here ]------------ Timed out after 60 seconds" and further debugging points to a possible circular locking dependency between the console_owner locking and the worker pool locking. Reverting the commit allows Steve's VM to boot to completion again. [ This may obviously result in the "[TTM] Buffer eviction failed" messages again, which was the reason for that original revert. But at this point this seems preferable to a non-booting system... ]
- https://git.kernel.org/stable/c/148ed8b4d64f94ab079c8f0d88c3f444db97ba97
- https://git.kernel.org/stable/c/3628e0383dd349f02f882e612ab6184e4bb3dc10
- https://git.kernel.org/stable/c/3dfe35d8683daf9ba69278643efbabe40000bbf6
- https://git.kernel.org/stable/c/4a89ac4b0921c4ea21eb1b4cf3a469a91bacfcea
- https://git.kernel.org/stable/c/b548c53bc3ab83dc6fc86c8e840f013b2032267a
- https://git.kernel.org/stable/c/148ed8b4d64f94ab079c8f0d88c3f444db97ba97
- https://git.kernel.org/stable/c/3628e0383dd349f02f882e612ab6184e4bb3dc10
- https://git.kernel.org/stable/c/3dfe35d8683daf9ba69278643efbabe40000bbf6
- https://git.kernel.org/stable/c/4a89ac4b0921c4ea21eb1b4cf3a469a91bacfcea
- https://git.kernel.org/stable/c/b548c53bc3ab83dc6fc86c8e840f013b2032267a
Modified: 2025-09-17
CVE-2024-36945
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.
- https://git.kernel.org/stable/c/2ddc0dd7fec86ee53b8928a5cca5fbddd4fc7c06
- https://git.kernel.org/stable/c/5df93c029a907b0ff5a4eeadd77ba06ff0a277d2
- https://git.kernel.org/stable/c/d5a466ab6e78d6f2e0f64435f1e17246c8e941ff
- https://git.kernel.org/stable/c/da91e447d06dc649fcf46e59122e7bf8f0b2e0db
- https://git.kernel.org/stable/c/2ddc0dd7fec86ee53b8928a5cca5fbddd4fc7c06
- https://git.kernel.org/stable/c/5df93c029a907b0ff5a4eeadd77ba06ff0a277d2
- https://git.kernel.org/stable/c/d5a466ab6e78d6f2e0f64435f1e17246c8e941ff
- https://git.kernel.org/stable/c/da91e447d06dc649fcf46e59122e7bf8f0b2e0db
- https://security.netapp.com/advisory/ntap-20250404-0006/
Modified: 2026-01-22
CVE-2024-36946
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)
- https://git.kernel.org/stable/c/4ff334cade9dae50e4be387f71e94fae634aa9b4
- https://git.kernel.org/stable/c/728a83160f98ee6b60df0d890141b9b7240182fe
- https://git.kernel.org/stable/c/9a77226440008cf04ba68faf641a2d50f4998137
- https://git.kernel.org/stable/c/d8cac8568618dcb8a51af3db1103e8d4cc4aeea7
- https://git.kernel.org/stable/c/dc6beac059f0331de97155a89d84058d4a9e49c7
- https://git.kernel.org/stable/c/ec1f71c05caeba0f814df77e0f511d8b4618623a
- https://git.kernel.org/stable/c/ee9e39a6cb3ca2a3d35b4ae25547ee3526a44d00
- https://git.kernel.org/stable/c/f085e02f0a32f6dfcfabc6535c9c4a1707cef86b
- https://git.kernel.org/stable/c/4ff334cade9dae50e4be387f71e94fae634aa9b4
- https://git.kernel.org/stable/c/728a83160f98ee6b60df0d890141b9b7240182fe
- https://git.kernel.org/stable/c/9a77226440008cf04ba68faf641a2d50f4998137
- https://git.kernel.org/stable/c/d8cac8568618dcb8a51af3db1103e8d4cc4aeea7
- https://git.kernel.org/stable/c/dc6beac059f0331de97155a89d84058d4a9e49c7
- https://git.kernel.org/stable/c/ec1f71c05caeba0f814df77e0f511d8b4618623a
- https://git.kernel.org/stable/c/ee9e39a6cb3ca2a3d35b4ae25547ee3526a44d00
- https://git.kernel.org/stable/c/f085e02f0a32f6dfcfabc6535c9c4a1707cef86b
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://security.netapp.com/advisory/ntap-20241004-0002/
Modified: 2025-09-17
CVE-2024-36947
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
- https://git.kernel.org/stable/c/02ee394a5d899d9bd2f0759382e9481cab6166f8
- https://git.kernel.org/stable/c/24dd9b08df718f20ccf2dd1519909fefd8c233ee
- https://git.kernel.org/stable/c/aa23317d0268b309bb3f0801ddd0d61813ff5afb
- https://git.kernel.org/stable/c/bd8f78c71defbcb7a9ed331e7f287507df972b00
- https://git.kernel.org/stable/c/db71ca93259dd1078bcfea3afafde2143cfc2da7
- https://git.kernel.org/stable/c/02ee394a5d899d9bd2f0759382e9481cab6166f8
- https://git.kernel.org/stable/c/24dd9b08df718f20ccf2dd1519909fefd8c233ee
- https://git.kernel.org/stable/c/aa23317d0268b309bb3f0801ddd0d61813ff5afb
- https://git.kernel.org/stable/c/bd8f78c71defbcb7a9ed331e7f287507df972b00
- https://git.kernel.org/stable/c/db71ca93259dd1078bcfea3afafde2143cfc2da7
Modified: 2025-12-17
CVE-2024-36950
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.
- https://git.kernel.org/stable/c/31279bbca40d2f40cb3bbb6d538ec9620a645dec
- https://git.kernel.org/stable/c/4f9cc355c328fc4f41cbd9c4cd58b235184fa420
- https://git.kernel.org/stable/c/5982887de60c1b84f9c0ca07c835814d07fd1da0
- https://git.kernel.org/stable/c/6fafe3661712b143d9c69a7322294bd53f559d5d
- https://git.kernel.org/stable/c/752e3c53de0fa3b7d817a83050b6699b8e9c6ec9
- https://git.kernel.org/stable/c/8643332aac0576581cfdf01798ea3e4e0d624b61
- https://git.kernel.org/stable/c/b3948c69d60279fce5b2eeda92a07d66296c8130
- https://git.kernel.org/stable/c/fa273f312334246c909475c5868e6daab889cc8c
- https://git.kernel.org/stable/c/31279bbca40d2f40cb3bbb6d538ec9620a645dec
- https://git.kernel.org/stable/c/4f9cc355c328fc4f41cbd9c4cd58b235184fa420
- https://git.kernel.org/stable/c/5982887de60c1b84f9c0ca07c835814d07fd1da0
- https://git.kernel.org/stable/c/6fafe3661712b143d9c69a7322294bd53f559d5d
- https://git.kernel.org/stable/c/752e3c53de0fa3b7d817a83050b6699b8e9c6ec9
- https://git.kernel.org/stable/c/8643332aac0576581cfdf01798ea3e4e0d624b61
- https://git.kernel.org/stable/c/b3948c69d60279fce5b2eeda92a07d66296c8130
- https://git.kernel.org/stable/c/fa273f312334246c909475c5868e6daab889cc8c
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-10-01
CVE-2024-36952
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.
- https://git.kernel.org/stable/c/0936809d968ecf81e0726fbd02ff2a5732d960c3
- https://git.kernel.org/stable/c/4ddf01f2f1504fa08b766e8cfeec558e9f8eef6c
- https://git.kernel.org/stable/c/718602cd15f4c5710850090ea3066a89eeb46278
- https://git.kernel.org/stable/c/76337eb8daee32bcc67742efab3168ed4ca299d0
- https://git.kernel.org/stable/c/f2c7f029051edc4b394bb48edbe2297575abefe0
- https://git.kernel.org/stable/c/0936809d968ecf81e0726fbd02ff2a5732d960c3
- https://git.kernel.org/stable/c/4ddf01f2f1504fa08b766e8cfeec558e9f8eef6c
- https://git.kernel.org/stable/c/718602cd15f4c5710850090ea3066a89eeb46278
- https://git.kernel.org/stable/c/76337eb8daee32bcc67742efab3168ed4ca299d0
- https://git.kernel.org/stable/c/f2c7f029051edc4b394bb48edbe2297575abefe0
Modified: 2025-12-23
CVE-2024-36953
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.
- https://git.kernel.org/stable/c/01981276d64e542c177b243f7c979fee855d5487
- https://git.kernel.org/stable/c/17db92da8be5dd3bf63c01f4109fe47db64fc66f
- https://git.kernel.org/stable/c/3a5b0378ac6776c7c31b18e0f3c1389bd6005e80
- https://git.kernel.org/stable/c/4404465a1bee3607ad90a4c5f9e16dfd75b85728
- https://git.kernel.org/stable/c/6ddb4f372fc63210034b903d96ebbeb3c7195adb
- https://git.kernel.org/stable/c/8d6a1c8e3de36cb0f5e866f1a582b00939e23104
- https://git.kernel.org/stable/c/01981276d64e542c177b243f7c979fee855d5487
- https://git.kernel.org/stable/c/17db92da8be5dd3bf63c01f4109fe47db64fc66f
- https://git.kernel.org/stable/c/3a5b0378ac6776c7c31b18e0f3c1389bd6005e80
- https://git.kernel.org/stable/c/4404465a1bee3607ad90a4c5f9e16dfd75b85728
- https://git.kernel.org/stable/c/6ddb4f372fc63210034b903d96ebbeb3c7195adb
- https://git.kernel.org/stable/c/8d6a1c8e3de36cb0f5e866f1a582b00939e23104
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
Modified: 2025-01-14
CVE-2024-36954
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.
- https://git.kernel.org/stable/c/01cd1b7b685751ee422d00d050292a3d277652d6
- https://git.kernel.org/stable/c/2f87fd9476cf9725d774e6dcb7d17859c6a6d1ae
- https://git.kernel.org/stable/c/3210d34fda4caff212cb53729e6bd46de604d565
- https://git.kernel.org/stable/c/42c8471b0566c7539e7dd584b4d0ebd3cec8cb2c
- https://git.kernel.org/stable/c/614c5a5ae45a921595952117b2e2bd4d4bf9b574
- https://git.kernel.org/stable/c/97bf6f81b29a8efaf5d0983251a7450e5794370d
- https://git.kernel.org/stable/c/adbce6d20da6254c86425a8d4359b221b5ccbccd
- https://git.kernel.org/stable/c/d03a82f4f8144befdc10518e732e2a60b34c870e
- https://git.kernel.org/stable/c/01cd1b7b685751ee422d00d050292a3d277652d6
- https://git.kernel.org/stable/c/2f87fd9476cf9725d774e6dcb7d17859c6a6d1ae
- https://git.kernel.org/stable/c/3210d34fda4caff212cb53729e6bd46de604d565
- https://git.kernel.org/stable/c/42c8471b0566c7539e7dd584b4d0ebd3cec8cb2c
- https://git.kernel.org/stable/c/614c5a5ae45a921595952117b2e2bd4d4bf9b574
- https://git.kernel.org/stable/c/97bf6f81b29a8efaf5d0983251a7450e5794370d
- https://git.kernel.org/stable/c/adbce6d20da6254c86425a8d4359b221b5ccbccd
- https://git.kernel.org/stable/c/d03a82f4f8144befdc10518e732e2a60b34c870e
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-04-01
CVE-2024-36955
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.
- https://git.kernel.org/stable/c/722d33c442e66e4aabd3e778958d696ff3a2777e
- https://git.kernel.org/stable/c/7db626d2730d3d80fd31638169054b1e507f07bf
- https://git.kernel.org/stable/c/7ef6ecf98ce309b1f4e5a25cddd5965d01feea07
- https://git.kernel.org/stable/c/bd2d9641a39e6b5244230c4b41c4aca83b54b377
- https://git.kernel.org/stable/c/c158cf914713efc3bcdc25680c7156c48c12ef6a
- https://git.kernel.org/stable/c/722d33c442e66e4aabd3e778958d696ff3a2777e
- https://git.kernel.org/stable/c/7db626d2730d3d80fd31638169054b1e507f07bf
- https://git.kernel.org/stable/c/7ef6ecf98ce309b1f4e5a25cddd5965d01feea07
- https://git.kernel.org/stable/c/bd2d9641a39e6b5244230c4b41c4aca83b54b377
- https://git.kernel.org/stable/c/c158cf914713efc3bcdc25680c7156c48c12ef6a
Modified: 2025-12-23
CVE-2024-36957
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.
- https://git.kernel.org/stable/c/0a0285cee11c7dcc2657bcd456e469958a5009e7
- https://git.kernel.org/stable/c/8f11fe3ea3fc261640cfc8a5addd838000407c67
- https://git.kernel.org/stable/c/bcdac70adceb44373da204c3c297f2a98e13216e
- https://git.kernel.org/stable/c/ec697fbd38cbe2eef0948b58673b146caa95402f
- https://git.kernel.org/stable/c/f299ee709fb45036454ca11e90cb2810fe771878
- https://git.kernel.org/stable/c/fc3e0076c1f82fe981d321e3a7bad4cbee542c19
- https://git.kernel.org/stable/c/0a0285cee11c7dcc2657bcd456e469958a5009e7
- https://git.kernel.org/stable/c/8f11fe3ea3fc261640cfc8a5addd838000407c67
- https://git.kernel.org/stable/c/bcdac70adceb44373da204c3c297f2a98e13216e
- https://git.kernel.org/stable/c/ec697fbd38cbe2eef0948b58673b146caa95402f
- https://git.kernel.org/stable/c/f299ee709fb45036454ca11e90cb2810fe771878
- https://git.kernel.org/stable/c/fc3e0076c1f82fe981d321e3a7bad4cbee542c19
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
Modified: 2025-01-14
CVE-2024-36959
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.
- https://git.kernel.org/stable/c/026e24cf31733dbd97f41cc9bc5273ace428eeec
- https://git.kernel.org/stable/c/06780473cb8a858d1d6cab2673e021b072a852d1
- https://git.kernel.org/stable/c/35ab679e8bb5a81a4f922d3efbd43e32bce69274
- https://git.kernel.org/stable/c/47d253c485491caaf70d8cd8c0248ae26e42581f
- https://git.kernel.org/stable/c/518d5ddafeb084d6d9b1773ed85164300037d0e6
- https://git.kernel.org/stable/c/76aa2440deb9a35507590f2c981a69a57ecd305d
- https://git.kernel.org/stable/c/a0cedbcc8852d6c77b00634b81e41f17f29d9404
- https://git.kernel.org/stable/c/c7e02ccc9fdc496fe51e440e3e66ac36509ca049
- https://git.kernel.org/stable/c/026e24cf31733dbd97f41cc9bc5273ace428eeec
- https://git.kernel.org/stable/c/06780473cb8a858d1d6cab2673e021b072a852d1
- https://git.kernel.org/stable/c/35ab679e8bb5a81a4f922d3efbd43e32bce69274
- https://git.kernel.org/stable/c/47d253c485491caaf70d8cd8c0248ae26e42581f
- https://git.kernel.org/stable/c/518d5ddafeb084d6d9b1773ed85164300037d0e6
- https://git.kernel.org/stable/c/76aa2440deb9a35507590f2c981a69a57ecd305d
- https://git.kernel.org/stable/c/a0cedbcc8852d6c77b00634b81e41f17f29d9404
- https://git.kernel.org/stable/c/c7e02ccc9fdc496fe51e440e3e66ac36509ca049
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-04-01
CVE-2024-36960
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.
- https://git.kernel.org/stable/c/0dbfc73670b357456196130551e586345ca48e1b
- https://git.kernel.org/stable/c/2f527e3efd37c7c5e85e8aa86308856b619fa59f
- https://git.kernel.org/stable/c/3cd682357c6167f636aec8ac0efaa8ba61144d36
- https://git.kernel.org/stable/c/7b5fd3af4a250dd0a2a558e07b43478748eb5d22
- https://git.kernel.org/stable/c/a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c
- https://git.kernel.org/stable/c/b7bab33c4623c66e3398d5253870d4e88c52dfc0
- https://git.kernel.org/stable/c/cef0962f2d3e5fd0660c8efb72321083a1b531a9
- https://git.kernel.org/stable/c/deab66596dfad14f1c54eeefdb72428340d72a77
- https://git.kernel.org/stable/c/0dbfc73670b357456196130551e586345ca48e1b
- https://git.kernel.org/stable/c/2f527e3efd37c7c5e85e8aa86308856b619fa59f
- https://git.kernel.org/stable/c/3cd682357c6167f636aec8ac0efaa8ba61144d36
- https://git.kernel.org/stable/c/7b5fd3af4a250dd0a2a558e07b43478748eb5d22
- https://git.kernel.org/stable/c/a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c
- https://git.kernel.org/stable/c/b7bab33c4623c66e3398d5253870d4e88c52dfc0
- https://git.kernel.org/stable/c/cef0962f2d3e5fd0660c8efb72321083a1b531a9
- https://git.kernel.org/stable/c/deab66596dfad14f1c54eeefdb72428340d72a77
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-10-01
CVE-2024-36962
In the Linux kernel, the following vulnerability has been resolved: net: ks8851: Queue RX packets in IRQ handler instead of disabling BHs Currently the driver uses local_bh_disable()/local_bh_enable() in its IRQ handler to avoid triggering net_rx_action() softirq on exit from netif_rx(). The net_rx_action() could trigger this driver .start_xmit callback, which is protected by the same lock as the IRQ handler, so calling the .start_xmit from netif_rx() from the IRQ handler critical section protected by the lock could lead to an attempt to claim the already claimed lock, and a hang. The local_bh_disable()/local_bh_enable() approach works only in case the IRQ handler is protected by a spinlock, but does not work if the IRQ handler is protected by mutex, i.e. this works for KS8851 with Parallel bus interface, but not for KS8851 with SPI bus interface. Remove the BH manipulation and instead of calling netif_rx() inside the IRQ handler code protected by the lock, queue all the received SKBs in the IRQ handler into a queue first, and once the IRQ handler exits the critical section protected by the lock, dequeue all the queued SKBs and push them all into netif_rx(). At this point, it is safe to trigger the net_rx_action() softirq, since the netif_rx() call is outside of the lock that protects the IRQ handler.
- https://git.kernel.org/stable/c/7e2901a2a9195da76111f351584bf77552a038f0
- https://git.kernel.org/stable/c/8a3ff43dcbab7c96f9e8cf2bd1049ab8d6e59545
- https://git.kernel.org/stable/c/ae87f661f3c1a3134a7ed86ab69bf9f12af88993
- https://git.kernel.org/stable/c/e0863634bf9f7cf36291ebb5bfa2d16632f79c49
- https://git.kernel.org/stable/c/7e2901a2a9195da76111f351584bf77552a038f0
- https://git.kernel.org/stable/c/8a3ff43dcbab7c96f9e8cf2bd1049ab8d6e59545
- https://git.kernel.org/stable/c/ae87f661f3c1a3134a7ed86ab69bf9f12af88993
- https://git.kernel.org/stable/c/e0863634bf9f7cf36291ebb5bfa2d16632f79c49
Modified: 2025-12-17
CVE-2024-36964
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.
- https://git.kernel.org/stable/c/157d468e34fdd3cb1ddc07c2be32fb3b02826b02
- https://git.kernel.org/stable/c/5a605930e19f451294bd838754f7d66c976a8a2c
- https://git.kernel.org/stable/c/ad4f65328661392de74e3608bb736fedf3b67e32
- https://git.kernel.org/stable/c/ca9b5c81f0c918c63d73d962ed8a8e231f840bc8
- https://git.kernel.org/stable/c/cd25e15e57e68a6b18dc9323047fe9c68b99290b
- https://git.kernel.org/stable/c/df1962a199783ecd66734d563caf0fedecf08f96
- https://git.kernel.org/stable/c/e55c601af3b1223a84f9f27f9cdbd2af5e203bf3
- https://git.kernel.org/stable/c/e90bc596a74bb905e0a45bf346038c3f9d1e868d
- https://git.kernel.org/stable/c/157d468e34fdd3cb1ddc07c2be32fb3b02826b02
- https://git.kernel.org/stable/c/5a605930e19f451294bd838754f7d66c976a8a2c
- https://git.kernel.org/stable/c/ad4f65328661392de74e3608bb736fedf3b67e32
- https://git.kernel.org/stable/c/ca9b5c81f0c918c63d73d962ed8a8e231f840bc8
- https://git.kernel.org/stable/c/cd25e15e57e68a6b18dc9323047fe9c68b99290b
- https://git.kernel.org/stable/c/df1962a199783ecd66734d563caf0fedecf08f96
- https://git.kernel.org/stable/c/e55c601af3b1223a84f9f27f9cdbd2af5e203bf3
- https://git.kernel.org/stable/c/e90bc596a74bb905e0a45bf346038c3f9d1e868d
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-11-03
CVE-2024-41011
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: don't allow mapping the MMIO HDP page with large pages We don't get the right offset in that case. The GPU has an unused 4K area of the register BAR space into which you can remap registers. We remap the HDP flush registers into this space to allow userspace (CPU or GPU) to flush the HDP when it updates VRAM. However, on systems with >4K pages, we end up exposing PAGE_SIZE of MMIO space.
- https://git.kernel.org/stable/c/009c4d78bcf07c4ac2e3dd9f275b4eaa72b4f884
- https://git.kernel.org/stable/c/4b4cff994a27ebf7bd3fb9a798a1cdfa8d01b724
- https://git.kernel.org/stable/c/6186c93560889265bfe0914609c274eff40bbeb5
- https://git.kernel.org/stable/c/89fffbdf535ce659c1a26b51ad62070566e33b28
- https://git.kernel.org/stable/c/8ad4838040e5515939c071a0f511ce2661a0889d
- https://git.kernel.org/stable/c/be4a2a81b6b90d1a47eaeaace4cc8e2cb57b96c7
- https://git.kernel.org/stable/c/f7276cdc1912325b64c33fcb1361952c06e55f63
- https://git.kernel.org/stable/c/4b4cff994a27ebf7bd3fb9a798a1cdfa8d01b724
- https://git.kernel.org/stable/c/6186c93560889265bfe0914609c274eff40bbeb5
- https://git.kernel.org/stable/c/89fffbdf535ce659c1a26b51ad62070566e33b28
- https://git.kernel.org/stable/c/be4a2a81b6b90d1a47eaeaace4cc8e2cb57b96c7
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
