ALT-BU-2024-17667-3
Branch p10 update bulletin.
Package kernel-image-std-def updated to version 5.10.217-alt1 for branch p10 in task 348293.
Closed vulnerabilities
Modified: 2026-03-04
BDU:2024-03934
Уязвимость функции packet_buffer_get() драйвера IEEE 1394 (FireWire) ядра операционной системы 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-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-04556
Уязвимость функции __fib6_rule_action() реализации протокола IPv6 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-09
BDU:2024-04557
Уязвимость функции tcp_twsk_unique() реализации протокола IPv4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2024-06522
Уязвимость компонента tcp ядра операционной системы 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-05-06
BDU:2024-10675
Уязвимость компонента phonet ядра операционной системы 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-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: 2025-08-19
BDU:2024-10686
Уязвимость компонента core ядра операционной системы 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: 2025-05-06
BDU:2024-10697
Уязвимость компонента h6 ядра операционной системы 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-10761
Уязвимость компонента ohci ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-11526
Уязвимость компонентов fs/9p ядра операционной системы 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: 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-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-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: 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: 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: 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: 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: 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: 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-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: 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-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-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-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-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
