ALT-BU-2021-4624-2
Branch sisyphus update bulletin.
Package python3-module-django updated to version 3.2.10-alt1 for branch sisyphus in task 292129.
Closed vulnerabilities
Modified: 2024-11-21
CVE-2021-44420
In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths.
- https://docs.djangoproject.com/en/3.2/releases/security/
- https://groups.google.com/forum/#%21forum/django-announce
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/B4SQG2EAF4WCI2SLRL6XRDJ3RPK3ZRDV/
- https://security.netapp.com/advisory/ntap-20211229-0006/
- https://www.djangoproject.com/weblog/2021/dec/07/security-releases/
- https://www.openwall.com/lists/oss-security/2021/12/07/1
- https://docs.djangoproject.com/en/3.2/releases/security/
- https://groups.google.com/forum/#%21forum/django-announce
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/B4SQG2EAF4WCI2SLRL6XRDJ3RPK3ZRDV/
- https://security.netapp.com/advisory/ntap-20211229-0006/
- https://www.djangoproject.com/weblog/2021/dec/07/security-releases/
- https://www.openwall.com/lists/oss-security/2021/12/07/1
Modified: 2024-11-18
GHSA-v6rh-hp5x-86rv
Potential bypass of an upstream access control based on URL paths in Django
- https://nvd.nist.gov/vuln/detail/CVE-2021-44420
- https://github.com/django/django/commit/d4dcd5b9dd9e462fec8220e33e3e6c822b7e88a6
- https://docs.djangoproject.com/en/3.2/releases/security
- https://github.com/advisories/GHSA-v6rh-hp5x-86rv
- https://github.com/django/django
- https://github.com/pypa/advisory-database/tree/main/vulns/django/PYSEC-2021-439.yaml
- https://groups.google.com/forum/#!forum/django-announce
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/B4SQG2EAF4WCI2SLRL6XRDJ3RPK3ZRDV
- https://security.netapp.com/advisory/ntap-20211229-0006
- https://www.djangoproject.com/weblog/2021/dec/07/security-releases
- https://www.openwall.com/lists/oss-security/2021/12/07/1
Package kernel-image-std-kvm updated to version 5.10.85-alt1 for branch sisyphus in task 292150.
Closed vulnerabilities
Modified: 2026-01-20
BDU:2022-00095
Уязвимость реализации функций close() и fget() ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании или повысить свои привилегии
Modified: 2024-11-07
BDU:2022-00828
Уязвимость функции postclose() ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2024-09-13
BDU:2022-04266
Уязвимость функции nci_request (net/nfc/nci/core.c) интерфейса контроллера NFC (NCI) ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2024-09-16
BDU:2024-03691
Уязвимость функции cfg80211_change_iface() в модуле net/wireless/util.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2024-04566
Уязвимость функции pch_can_rx_normal() драйвера Controller Area Network (CAN) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2024-04567
Уязвимость функции ems_pcmcia_add_card() драйвера устройств Philips/NXP SJA1000 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2024-04569
Уязвимость функции mlx4_en_try_alloc_resources() драйвера сетевых адаптеров Mellanox Technologies 1/10/40Gbit ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2024-04570
Уязвимость функции _rtl92e_pci_disconnect() драйвера беспроводного адаптера RealTek RTL8192E ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-10-11
BDU:2024-07477
Уязвимость функции sched_fork() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-11-27
BDU:2024-09144
Уязвимость компонента advansys ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2024-09177
Уязвимость компонента scsi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-27
BDU:2024-09178
Уязвимость компонента selinux ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-27
BDU:2024-09209
Уязвимость компонента tusb6010 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-27
BDU:2024-09210
Уязвимость компонента i40e ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09211
Уязвимость компонента tty_buffer ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-27
BDU:2024-09212
Уязвимость компонента tipc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-27
BDU:2024-09213
Уязвимость компонента arm64 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-27
BDU:2024-09214
Уязвимость компонента btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-27
BDU:2024-09215
Уязвимость компонента perf bpf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2024-09218
Уязвимость компонента scsi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-27
BDU:2024-09219
Уязвимость компонента scsi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-27
BDU:2024-09221
Уязвимость компонента mlx5e ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-27
BDU:2024-09223
Уязвимость компонента iavf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-27
BDU:2024-09224
Уязвимость компонента thermal ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-27
BDU:2024-09225
Уязвимость компонента lpfc ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2024-11-27
BDU:2024-09226
Уязвимость компонента dpaa2-eth ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2024-11-27
BDU:2024-09228
Уязвимость компонента ohci-tmio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-27
BDU:2024-09229
Уязвимость компонента gus ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-27
BDU:2024-09231
Уязвимость компонента typec ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-27
BDU:2024-09232
Уязвимость компонента hyperv ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10531
Уязвимость компонентов IB/hfi1 ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
BDU:2024-10574
Уязвимость компонента seg6 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10575
Уязвимость компонента devlink ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
BDU:2024-10576
Уязвимость компонента fq_pie ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10577
Уязвимость компонента ALSA ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10579
Уязвимость функции hns_dsaf_ge_srst_by_port() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2024-10580
Уязвимость компонента oss ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10582
Уязвимость компонента nfsd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10583
Уязвимость компонента nfsd ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2026-01-20
BDU:2024-10584
Уязвимость компонента aio ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
BDU:2024-10586
Уязвимость компонента pm80xx ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10587
Уязвимость компонента AsoC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-05
BDU:2024-10590
Уязвимость компонента i40e ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10591
Уязвимость компонента mma8452 ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
BDU:2024-10592
Уязвимость компонента kxcjk-1013 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10663
Уязвимость компонентов powerpc/32 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10664
Уязвимость компонентов proc/vmcore ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10665
Уязвимость компонента mpt3sas ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10666
Уязвимость компонента prestera ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10667
Уязвимость компонента ice ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
BDU:2024-10668
Уязвимость компонента ice ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10670
Уязвимость компонента spectrum ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10672
Уязвимость компонента sch_ets ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10673
Уязвимость компонента vlan ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10728
Уязвимость компонентов sched/scs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10730
Уязвимость компонентов drm/amd/amdkfd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10731
Уязвимость компонента sata_fsl ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
BDU:2024-10736
Уязвимость компонента de4x5 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10737
Уязвимость компонентов tcp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10740
Уязвимость компонента rxrpc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10745
Уязвимость компонентов net/smc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10748
Уязвимость компонентов drm/msm/a6xx ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10763
Уязвимость компонента rxrpc ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
Modified: 2025-08-19
BDU:2024-10766
Уязвимость компонента core ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-04359
Уязвимость функции nh_create_ipv6() модуля net/ipv4/nexthop.c реализации протокола IPv4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-04360
Уязвимость функции fib4_rule_action() модуля net/ipv4/fib_rules.c реализации протокола IPv4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-04378
Уязвимость функции nfp_cpp_area_cache_add() модуля drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c - драйвера поддержки сетевых адаптеров Ethernet ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
BDU:2025-04459
Уязвимость функции amdgpu_get_xgmi_hive() модуля drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c - драйвера поддержки инфраструктуры прямого рендеринга (DRI) AMD GPU ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-04460
Уязвимость функции qlcnic_83xx_add_rings() модуля drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c - драйвера поддержки сетевых адаптеров Ethernet Qlogic ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-04462
Уязвимость функции nfc_genl_dump_ses_done() модуля net/nfc/netlink.c подсистемы NFC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14241
Уязвимость функции bigben_worker() модуля drivers/hid/hid-bigbenff.c драйвера подсистемы устройств пользовательского интерфейса ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
BDU:2025-14246
Уязвимость функции mt7915_get_phy_mode() модуля drivers/net/wireless/mediatek/mt76/mt7915/mcu.c драйвера поддержки адаптеров беспроводной связи ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14247
Уязвимость функции smc_link_down_work() модуля net/smc/smc_core.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-21
CVE-2020-27820
A vulnerability was found in Linux kernel, where a use-after-frees in nouveau's postclose() handler could happen if removing device (that is not common to remove video card physically without power-off, but same happens if "unbind" the driver).
- https://bugzilla.redhat.com/show_bug.cgi?id=1901726
- https://lore.kernel.org/dri-devel/20201103194912.184413-2-jcline%40redhat.com/
- https://lore.kernel.org/dri-devel/20201103194912.184413-3-jcline%40redhat.com/
- https://lore.kernel.org/dri-devel/20201103194912.184413-4-jcline%40redhat.com/
- https://www.oracle.com/security-alerts/cpujul2022.html
- https://bugzilla.redhat.com/show_bug.cgi?id=1901726
- https://lore.kernel.org/dri-devel/20201103194912.184413-2-jcline%40redhat.com/
- https://lore.kernel.org/dri-devel/20201103194912.184413-3-jcline%40redhat.com/
- https://lore.kernel.org/dri-devel/20201103194912.184413-4-jcline%40redhat.com/
- https://www.oracle.com/security-alerts/cpujul2022.html
Modified: 2024-11-21
CVE-2021-4083
A read-after-free memory flaw was found in the Linux kernel's garbage collection for Unix domain socket file handlers in the way users call close() and fget() simultaneously and can potentially trigger a race condition. This flaw allows a local user to crash the system or escalate their privileges on the system. This flaw affects Linux kernel versions prior to 5.16-rc4.
- https://bugzilla.redhat.com/show_bug.cgi?id=2029923
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=054aa8d439b9
- https://lists.debian.org/debian-lts-announce/2022/03/msg00011.html
- https://lists.debian.org/debian-lts-announce/2022/03/msg00012.html
- https://security.netapp.com/advisory/ntap-20220217-0005/
- https://www.debian.org/security/2022/dsa-5096
- https://www.oracle.com/security-alerts/cpujul2022.html
- https://bugzilla.redhat.com/show_bug.cgi?id=2029923
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=054aa8d439b9
- https://lists.debian.org/debian-lts-announce/2022/03/msg00011.html
- https://lists.debian.org/debian-lts-announce/2022/03/msg00012.html
- https://security.netapp.com/advisory/ntap-20220217-0005/
- https://www.debian.org/security/2022/dsa-5096
- https://www.oracle.com/security-alerts/cpujul2022.html
Modified: 2024-11-21
CVE-2021-4202
A use-after-free flaw was found in nci_request in net/nfc/nci/core.c in NFC Controller Interface (NCI) in the Linux kernel. This flaw could allow a local attacker with user privileges to cause a data race problem while the device is getting removed, leading to a privilege escalation problem.
- http://www.openwall.com/lists/oss-security/2022/06/01/2
- http://www.openwall.com/lists/oss-security/2022/06/04/2
- http://www.openwall.com/lists/oss-security/2022/06/07/2
- https://bugzilla.redhat.com/show_bug.cgi?id=2036682
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=3e3b5dfcd16a3e254aab61bd1e8c417dd4503102
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=48b71a9e66c2eab60564b1b1c85f4928ed04e406
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=86cdf8e38792545161dbe3350a7eced558ba4d15
- https://security.netapp.com/advisory/ntap-20220513-0002/
- http://www.openwall.com/lists/oss-security/2022/06/01/2
- http://www.openwall.com/lists/oss-security/2022/06/04/2
- http://www.openwall.com/lists/oss-security/2022/06/07/2
- https://bugzilla.redhat.com/show_bug.cgi?id=2036682
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=3e3b5dfcd16a3e254aab61bd1e8c417dd4503102
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=48b71a9e66c2eab60564b1b1c85f4928ed04e406
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=86cdf8e38792545161dbe3350a7eced558ba4d15
- https://security.netapp.com/advisory/ntap-20220513-0002/
Modified: 2024-12-20
CVE-2021-47181
In the Linux kernel, the following vulnerability has been resolved: usb: musb: tusb6010: check return value after calling platform_get_resource() It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value.
- https://git.kernel.org/stable/c/06cfb4cb2241e704d72e3045cf4d7dfb567fbce0
- https://git.kernel.org/stable/c/14651496a3de6807a17c310f63c894ea0c5d858e
- https://git.kernel.org/stable/c/1ba7605856e05fa991d4654ac69e5ace66c767b9
- https://git.kernel.org/stable/c/28be095eb612a489705d38c210afaf1103c5f4f8
- https://git.kernel.org/stable/c/3ee15f1af17407be381bcf06a78fa60b471242dd
- https://git.kernel.org/stable/c/679eee466d0f9ffa60a2b0c6ec19be5128927f04
- https://git.kernel.org/stable/c/b3f43659eb0b9af2e6ef18a8d829374610b19e7a
- https://git.kernel.org/stable/c/f87a79c04a33ab4e5be598c7b0867e6ef193d702
- https://git.kernel.org/stable/c/06cfb4cb2241e704d72e3045cf4d7dfb567fbce0
- https://git.kernel.org/stable/c/14651496a3de6807a17c310f63c894ea0c5d858e
- https://git.kernel.org/stable/c/1ba7605856e05fa991d4654ac69e5ace66c767b9
- https://git.kernel.org/stable/c/28be095eb612a489705d38c210afaf1103c5f4f8
- https://git.kernel.org/stable/c/3ee15f1af17407be381bcf06a78fa60b471242dd
- https://git.kernel.org/stable/c/679eee466d0f9ffa60a2b0c6ec19be5128927f04
- https://git.kernel.org/stable/c/b3f43659eb0b9af2e6ef18a8d829374610b19e7a
- https://git.kernel.org/stable/c/f87a79c04a33ab4e5be598c7b0867e6ef193d702
Modified: 2025-01-14
CVE-2021-47184
In the Linux kernel, the following vulnerability has been resolved: i40e: Fix NULL ptr dereference on VSI filter sync Remove the reason of null pointer dereference in sync VSI filters. Added new I40E_VSI_RELEASING flag to signalize deleting and releasing of VSI resources to sync this thread with sync filters subtask. Without this patch it is possible to start update the VSI filter list after VSI is removed, that's causing a kernel oops.
- https://git.kernel.org/stable/c/37d9e304acd903a445df8208b8a13d707902dea6
- https://git.kernel.org/stable/c/78f2a9e831f9610e3655a0be5e675e1aa2472089
- https://git.kernel.org/stable/c/87c421ab4a43433cb009fea44bbbc77f46913e1d
- https://git.kernel.org/stable/c/c30162da91327e4cdf7cd03079f096bb3654738c
- https://git.kernel.org/stable/c/e91e8427a1e1633a0261e3bb0201c836ac5b3890
- https://git.kernel.org/stable/c/f866513ead4370402428ef724b03c3312295c178
- https://git.kernel.org/stable/c/37d9e304acd903a445df8208b8a13d707902dea6
- https://git.kernel.org/stable/c/78f2a9e831f9610e3655a0be5e675e1aa2472089
- https://git.kernel.org/stable/c/87c421ab4a43433cb009fea44bbbc77f46913e1d
- https://git.kernel.org/stable/c/c30162da91327e4cdf7cd03079f096bb3654738c
- https://git.kernel.org/stable/c/e91e8427a1e1633a0261e3bb0201c836ac5b3890
- https://git.kernel.org/stable/c/f866513ead4370402428ef724b03c3312295c178
Modified: 2025-03-21
CVE-2021-47185
In the Linux kernel, the following vulnerability has been resolved: tty: tty_buffer: Fix the softlockup issue in flush_to_ldisc When running ltp testcase(ltp/testcases/kernel/pty/pty04.c) with arm64, there is a soft lockup, which look like this one: Workqueue: events_unbound flush_to_ldisc Call trace: dump_backtrace+0x0/0x1ec show_stack+0x24/0x30 dump_stack+0xd0/0x128 panic+0x15c/0x374 watchdog_timer_fn+0x2b8/0x304 __run_hrtimer+0x88/0x2c0 __hrtimer_run_queues+0xa4/0x120 hrtimer_interrupt+0xfc/0x270 arch_timer_handler_phys+0x40/0x50 handle_percpu_devid_irq+0x94/0x220 __handle_domain_irq+0x88/0xf0 gic_handle_irq+0x84/0xfc el1_irq+0xc8/0x180 slip_unesc+0x80/0x214 [slip] tty_ldisc_receive_buf+0x64/0x80 tty_port_default_receive_buf+0x50/0x90 flush_to_ldisc+0xbc/0x110 process_one_work+0x1d4/0x4b0 worker_thread+0x180/0x430 kthread+0x11c/0x120 In the testcase pty04, The first process call the write syscall to send data to the pty master. At the same time, the workqueue will do the flush_to_ldisc to pop data in a loop until there is no more data left. When the sender and workqueue running in different core, the sender sends data fastly in full time which will result in workqueue doing work in loop for a long time and occuring softlockup in flush_to_ldisc with kernel configured without preempt. So I add need_resched check and cond_resched in the flush_to_ldisc loop to avoid it.
- https://git.kernel.org/stable/c/0380f643f3a7a61b0845cdc738959c2ad5735d61
- https://git.kernel.org/stable/c/3968ddcf05fb4b9409cd1859feb06a5b0550a1c1
- https://git.kernel.org/stable/c/4c1623651a0936ee197859824cdae6ebbd04d3ed
- https://git.kernel.org/stable/c/4f300f47dbcf9c3d4b2ea76c8554c8f360400725
- https://git.kernel.org/stable/c/5c34486f04700f1ba04907231dce0cc2705c2d7d
- https://git.kernel.org/stable/c/77e9fed33056f2a88eba9dd4d2d5412f0c7d1f41
- https://git.kernel.org/stable/c/b1ffc16ec05ae40d82b6e373322d62e9d6b54fbc
- https://git.kernel.org/stable/c/d491c84df5c469dd9621863b6a770b3428137063
- https://git.kernel.org/stable/c/0380f643f3a7a61b0845cdc738959c2ad5735d61
- https://git.kernel.org/stable/c/3968ddcf05fb4b9409cd1859feb06a5b0550a1c1
- https://git.kernel.org/stable/c/4c1623651a0936ee197859824cdae6ebbd04d3ed
- https://git.kernel.org/stable/c/4f300f47dbcf9c3d4b2ea76c8554c8f360400725
- https://git.kernel.org/stable/c/5c34486f04700f1ba04907231dce0cc2705c2d7d
- https://git.kernel.org/stable/c/77e9fed33056f2a88eba9dd4d2d5412f0c7d1f41
- https://git.kernel.org/stable/c/b1ffc16ec05ae40d82b6e373322d62e9d6b54fbc
- https://git.kernel.org/stable/c/d491c84df5c469dd9621863b6a770b3428137063
Modified: 2025-03-04
CVE-2021-47186
In the Linux kernel, the following vulnerability has been resolved: tipc: check for null after calling kmemdup kmemdup can return a null pointer so need to check for it, otherwise the null key will be dereferenced later in tipc_crypto_key_xmit as can be seen in the trace [1]. [1] https://syzkaller.appspot.com/bug?id=bca180abb29567b189efdbdb34cbf7ba851c2a58
- https://git.kernel.org/stable/c/3e6db079751afd527bf3db32314ae938dc571916
- https://git.kernel.org/stable/c/9404c4145542c23019a80ab1bb2ecf73cd057b10
- https://git.kernel.org/stable/c/a7d91625863d4ffed63b993b5e6dc1298b6430c9
- https://git.kernel.org/stable/c/3e6db079751afd527bf3db32314ae938dc571916
- https://git.kernel.org/stable/c/9404c4145542c23019a80ab1bb2ecf73cd057b10
- https://git.kernel.org/stable/c/a7d91625863d4ffed63b993b5e6dc1298b6430c9
Modified: 2025-03-21
CVE-2021-47187
In the Linux kernel, the following vulnerability has been resolved: arm64: dts: qcom: msm8998: Fix CPU/L2 idle state latency and residency The entry/exit latency and minimum residency in state for the idle states of MSM8998 were ..bad: first of all, for all of them the timings were written for CPU sleep but the min-residency-us param was miscalculated (supposedly, while porting this from downstream); Then, the power collapse states are setting PC on both the CPU cluster *and* the L2 cache, which have different timings: in the specific case of L2 the times are higher so these ones should be taken into account instead of the CPU ones. This parameter misconfiguration was not giving particular issues because on MSM8998 there was no CPU scaling at all, so cluster/L2 power collapse was rarely (if ever) hit. When CPU scaling is enabled, though, the wrong timings will produce SoC unstability shown to the user as random, apparently error-less, sudden reboots and/or lockups. This set of parameters are stabilizing the SoC when CPU scaling is ON and when power collapse is frequently hit.
- https://git.kernel.org/stable/c/118c826ef8b43efe0fda8faf419673707ee8c5e5
- https://git.kernel.org/stable/c/3f1dcaff642e75c1d2ad03f783fa8a3b1f56dd50
- https://git.kernel.org/stable/c/a14d7038ea201c5526375becfc43b9ba281b1e82
- https://git.kernel.org/stable/c/e52fecdd0c142b95c720683885b06ee3f0e065c8
- https://git.kernel.org/stable/c/118c826ef8b43efe0fda8faf419673707ee8c5e5
- https://git.kernel.org/stable/c/3f1dcaff642e75c1d2ad03f783fa8a3b1f56dd50
- https://git.kernel.org/stable/c/a14d7038ea201c5526375becfc43b9ba281b1e82
- https://git.kernel.org/stable/c/e52fecdd0c142b95c720683885b06ee3f0e065c8
Modified: 2025-04-30
CVE-2021-47189
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix memory ordering between normal and ordered work functions
Ordered work functions aren't guaranteed to be handled by the same thread
which executed the normal work functions. The only way execution between
normal/ordered functions is synchronized is via the WORK_DONE_BIT,
unfortunately the used bitops don't guarantee any ordering whatsoever.
This manifested as seemingly inexplicable crashes on ARM64, where
async_chunk::inode is seen as non-null in async_cow_submit which causes
submit_compressed_extents to be called and crash occurs because
async_chunk::inode suddenly became NULL. The call trace was similar to:
pc : submit_compressed_extents+0x38/0x3d0
lr : async_cow_submit+0x50/0xd0
sp : ffff800015d4bc20
- https://git.kernel.org/stable/c/45da9c1767ac31857df572f0a909fbe88fd5a7e9
- https://git.kernel.org/stable/c/47e6f9f69153247109042010f3a77579e9dc61ff
- https://git.kernel.org/stable/c/637d652d351fd4f263ef302dc52f3971d314e500
- https://git.kernel.org/stable/c/670f6b3867c8f0f11e5097f353b164cecfec6179
- https://git.kernel.org/stable/c/6adbc07ebcaf8bead08b21687d49e0fc94400987
- https://git.kernel.org/stable/c/804a9d239ae9cbe88e861a7cd62319cc6ec7b136
- https://git.kernel.org/stable/c/bd660a20fea3ec60a49709ef5360f145ec0fe779
- https://git.kernel.org/stable/c/ed058d735a70f4b063323f1a7bb33cda0f987513
- https://git.kernel.org/stable/c/45da9c1767ac31857df572f0a909fbe88fd5a7e9
- https://git.kernel.org/stable/c/47e6f9f69153247109042010f3a77579e9dc61ff
- https://git.kernel.org/stable/c/637d652d351fd4f263ef302dc52f3971d314e500
- https://git.kernel.org/stable/c/670f6b3867c8f0f11e5097f353b164cecfec6179
- https://git.kernel.org/stable/c/6adbc07ebcaf8bead08b21687d49e0fc94400987
- https://git.kernel.org/stable/c/804a9d239ae9cbe88e861a7cd62319cc6ec7b136
- https://git.kernel.org/stable/c/bd660a20fea3ec60a49709ef5360f145ec0fe779
- https://git.kernel.org/stable/c/ed058d735a70f4b063323f1a7bb33cda0f987513
Modified: 2025-01-07
CVE-2021-47190
In the Linux kernel, the following vulnerability has been resolved: perf bpf: Avoid memory leak from perf_env__insert_btf() perf_env__insert_btf() doesn't insert if a duplicate BTF id is encountered and this causes a memory leak. Modify the function to return a success/error value and then free the memory if insertion didn't happen. v2. Adds a return -1 when the insertion error occurs in perf_env__fetch_btf. This doesn't affect anything as the result is never checked.
- https://git.kernel.org/stable/c/11589d3144bc4e272e0aae46ce8156162e99babc
- https://git.kernel.org/stable/c/4924b1f7c46711762fd0e65c135ccfbcfd6ded1f
- https://git.kernel.org/stable/c/642fc22210a5e59d40b1e4d56d21ec3effd401f2
- https://git.kernel.org/stable/c/ab7c3d8d81c511ddfb27823fb07081c96422b56e
- https://git.kernel.org/stable/c/11589d3144bc4e272e0aae46ce8156162e99babc
- https://git.kernel.org/stable/c/4924b1f7c46711762fd0e65c135ccfbcfd6ded1f
- https://git.kernel.org/stable/c/642fc22210a5e59d40b1e4d56d21ec3effd401f2
- https://git.kernel.org/stable/c/ab7c3d8d81c511ddfb27823fb07081c96422b56e
Modified: 2025-01-14
CVE-2021-47191
In the Linux kernel, the following vulnerability has been resolved: scsi: scsi_debug: Fix out-of-bound read in resp_readcap16() The following warning was observed running syzkaller: [ 3813.830724] sg_write: data in/out 65466/242 bytes for SCSI command 0x9e-- guessing data in; [ 3813.830724] program syz-executor not setting count and/or reply_len properly [ 3813.836956] ================================================================== [ 3813.839465] BUG: KASAN: stack-out-of-bounds in sg_copy_buffer+0x157/0x1e0 [ 3813.841773] Read of size 4096 at addr ffff8883cf80f540 by task syz-executor/1549 [ 3813.846612] Call Trace: [ 3813.846995] dump_stack+0x108/0x15f [ 3813.847524] print_address_description+0xa5/0x372 [ 3813.848243] kasan_report.cold+0x236/0x2a8 [ 3813.849439] check_memory_region+0x240/0x270 [ 3813.850094] memcpy+0x30/0x80 [ 3813.850553] sg_copy_buffer+0x157/0x1e0 [ 3813.853032] sg_copy_from_buffer+0x13/0x20 [ 3813.853660] fill_from_dev_buffer+0x135/0x370 [ 3813.854329] resp_readcap16+0x1ac/0x280 [ 3813.856917] schedule_resp+0x41f/0x1630 [ 3813.858203] scsi_debug_queuecommand+0xb32/0x17e0 [ 3813.862699] scsi_dispatch_cmd+0x330/0x950 [ 3813.863329] scsi_request_fn+0xd8e/0x1710 [ 3813.863946] __blk_run_queue+0x10b/0x230 [ 3813.864544] blk_execute_rq_nowait+0x1d8/0x400 [ 3813.865220] sg_common_write.isra.0+0xe61/0x2420 [ 3813.871637] sg_write+0x6c8/0xef0 [ 3813.878853] __vfs_write+0xe4/0x800 [ 3813.883487] vfs_write+0x17b/0x530 [ 3813.884008] ksys_write+0x103/0x270 [ 3813.886268] __x64_sys_write+0x77/0xc0 [ 3813.886841] do_syscall_64+0x106/0x360 [ 3813.887415] entry_SYSCALL_64_after_hwframe+0x44/0xa9 This issue can be reproduced with the following syzkaller log: r0 = openat(0xffffffffffffff9c, &(0x7f0000000040)='./file0\x00', 0x26e1, 0x0) r1 = syz_open_procfs(0xffffffffffffffff, &(0x7f0000000000)='fd/3\x00') open_by_handle_at(r1, &(0x7f00000003c0)=ANY=[@ANYRESHEX], 0x602000) r2 = syz_open_dev$sg(&(0x7f0000000000), 0x0, 0x40782) write$binfmt_aout(r2, &(0x7f0000000340)=ANY=[@ANYBLOB="00000000deff000000000000000000000000000000000000000000000000000047f007af9e107a41ec395f1bded7be24277a1501ff6196a83366f4e6362bc0ff2b247f68a972989b094b2da4fb3607fcf611a22dd04310d28c75039d"], 0x126) In resp_readcap16() we get "int alloc_len" value -1104926854, and then pass the huge arr_len to fill_from_dev_buffer(), but arr is only 32 bytes. This leads to OOB in sg_copy_buffer(). To solve this issue, define alloc_len as u32.
- https://git.kernel.org/stable/c/3e20cb072679bdb47747ccc8bee3233a4cf0765a
- https://git.kernel.org/stable/c/4e3ace0051e7e504b55d239daab8789dd89b863c
- https://git.kernel.org/stable/c/5b8bed6464ad6653586e30df046185fd816ad999
- https://git.kernel.org/stable/c/3e20cb072679bdb47747ccc8bee3233a4cf0765a
- https://git.kernel.org/stable/c/4e3ace0051e7e504b55d239daab8789dd89b863c
- https://git.kernel.org/stable/c/5b8bed6464ad6653586e30df046185fd816ad999
Modified: 2025-04-30
CVE-2021-47192
In the Linux kernel, the following vulnerability has been resolved: scsi: core: sysfs: Fix hang when device state is set via sysfs This fixes a regression added with: commit f0f82e2476f6 ("scsi: core: Fix capacity set to zero after offlinining device") The problem is that after iSCSI recovery, iscsid will call into the kernel to set the dev's state to running, and with that patch we now call scsi_rescan_device() with the state_mutex held. If the SCSI error handler thread is just starting to test the device in scsi_send_eh_cmnd() then it's going to try to grab the state_mutex. We are then stuck, because when scsi_rescan_device() tries to send its I/O scsi_queue_rq() calls -> scsi_host_queue_ready() -> scsi_host_in_recovery() which will return true (the host state is still in recovery) and I/O will just be requeued. scsi_send_eh_cmnd() will then never be able to grab the state_mutex to finish error handling. To prevent the deadlock move the rescan-related code to after we drop the state_mutex. This also adds a check for if we are already in the running state. This prevents extra scans and helps the iscsid case where if the transport class has already onlined the device during its recovery process then we don't need userspace to do it again plus possibly block that daemon.
- https://git.kernel.org/stable/c/4edd8cd4e86dd3047e5294bbefcc0a08f66a430f
- https://git.kernel.org/stable/c/a792e0128d232251edb5fdf42fb0f9fbb0b44a73
- https://git.kernel.org/stable/c/bcc0e3175a976b7fa9a353960808adb0bb49ead8
- https://git.kernel.org/stable/c/edd783162bf2385b43de6764f2d4c6e9f4f6be27
- https://git.kernel.org/stable/c/4edd8cd4e86dd3047e5294bbefcc0a08f66a430f
- https://git.kernel.org/stable/c/a792e0128d232251edb5fdf42fb0f9fbb0b44a73
- https://git.kernel.org/stable/c/bcc0e3175a976b7fa9a353960808adb0bb49ead8
- https://git.kernel.org/stable/c/edd783162bf2385b43de6764f2d4c6e9f4f6be27
Modified: 2024-11-21
CVE-2021-47194
In the Linux kernel, the following vulnerability has been resolved: cfg80211: call cfg80211_stop_ap when switch from P2P_GO type If the userspace tools switch from NL80211_IFTYPE_P2P_GO to NL80211_IFTYPE_ADHOC via send_msg(NL80211_CMD_SET_INTERFACE), it does not call the cleanup cfg80211_stop_ap(), this leads to the initialization of in-use data. For example, this path re-init the sdata->assigned_chanctx_list while it is still an element of assigned_vifs list, and makes that linked list corrupt.
- https://git.kernel.org/stable/c/0738cdb636c21ab552eaecf905efa4a6070e3ebc
- https://git.kernel.org/stable/c/4e458abbb4a523f1413bfe15c079cf4e24c15b21
- https://git.kernel.org/stable/c/52affc201fc22a1ab9a59ef0ed641a9adfcb8d13
- https://git.kernel.org/stable/c/563fbefed46ae4c1f70cffb8eb54c02df480b2c2
- https://git.kernel.org/stable/c/5a9b671c8d74a3e1b999e7a0c7f366079bcc93dd
- https://git.kernel.org/stable/c/7b97b5776daa0b39dbdadfea176f9cc0646d4a66
- https://git.kernel.org/stable/c/8f06bb8c216bcd172394f61e557727e691b4cb24
- https://git.kernel.org/stable/c/b8a045e2a9b234cfbc06cf36923886164358ddec
- https://git.kernel.org/stable/c/0738cdb636c21ab552eaecf905efa4a6070e3ebc
- https://git.kernel.org/stable/c/4e458abbb4a523f1413bfe15c079cf4e24c15b21
- https://git.kernel.org/stable/c/52affc201fc22a1ab9a59ef0ed641a9adfcb8d13
- https://git.kernel.org/stable/c/563fbefed46ae4c1f70cffb8eb54c02df480b2c2
- https://git.kernel.org/stable/c/5a9b671c8d74a3e1b999e7a0c7f366079bcc93dd
- https://git.kernel.org/stable/c/7b97b5776daa0b39dbdadfea176f9cc0646d4a66
- https://git.kernel.org/stable/c/8f06bb8c216bcd172394f61e557727e691b4cb24
- https://git.kernel.org/stable/c/b8a045e2a9b234cfbc06cf36923886164358ddec
Modified: 2025-03-21
CVE-2021-47197
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: nullify cq->dbg pointer in mlx5_debug_cq_remove() Prior to this patch in case mlx5_core_destroy_cq() failed it proceeds to rest of destroy operations. mlx5_core_destroy_cq() could be called again by user and cause additional call of mlx5_debug_cq_remove(). cq->dbg was not nullify in previous call and cause the crash. Fix it by nullify cq->dbg pointer after removal. Also proceed to destroy operations only if FW return 0 for MLX5_CMD_OP_DESTROY_CQ command. general protection fault, probably for non-canonical address 0x2000300004058: 0000 [#1] SMP PTI CPU: 5 PID: 1228 Comm: python Not tainted 5.15.0-rc5_for_upstream_min_debug_2021_10_14_11_06 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:lockref_get+0x1/0x60 Code: 5d e9 53 ff ff ff 48 8d 7f 70 e8 0a 2e 48 00 c7 85 d0 00 00 00 02 00 00 00 c6 45 70 00 fb 5d c3 c3 cc cc cc cc cc cc cc cc 53 <48> 8b 17 48 89 fb 85 d2 75 3d 48 89 d0 bf 64 00 00 00 48 89 c1 48 RSP: 0018:ffff888137dd7a38 EFLAGS: 00010206 RAX: 0000000000000000 RBX: ffff888107d5f458 RCX: 00000000fffffffe RDX: 000000000002c2b0 RSI: ffffffff8155e2e0 RDI: 0002000300004058 RBP: ffff888137dd7a88 R08: 0002000300004058 R09: ffff8881144a9f88 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8881141d4000 R13: ffff888137dd7c68 R14: ffff888137dd7d58 R15: ffff888137dd7cc0 FS: 00007f4644f2a4c0(0000) GS:ffff8887a2d40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055b4500f4380 CR3: 0000000114f7a003 CR4: 0000000000170ea0 Call Trace: simple_recursive_removal+0x33/0x2e0 ? debugfs_remove+0x60/0x60 debugfs_remove+0x40/0x60 mlx5_debug_cq_remove+0x32/0x70 [mlx5_core] mlx5_core_destroy_cq+0x41/0x1d0 [mlx5_core] devx_obj_cleanup+0x151/0x330 [mlx5_ib] ? __pollwait+0xd0/0xd0 ? xas_load+0x5/0x70 ? xa_load+0x62/0xa0 destroy_hw_idr_uobject+0x20/0x80 [ib_uverbs] uverbs_destroy_uobject+0x3b/0x360 [ib_uverbs] uobj_destroy+0x54/0xa0 [ib_uverbs] ib_uverbs_cmd_verbs+0xaf2/0x1160 [ib_uverbs] ? uverbs_finalize_object+0xd0/0xd0 [ib_uverbs] ib_uverbs_ioctl+0xc4/0x1b0 [ib_uverbs] __x64_sys_ioctl+0x3e4/0x8e0
- https://git.kernel.org/stable/c/2ae38157080616a13a9fe3f0b4b6ec0070aa408a
- https://git.kernel.org/stable/c/471c492890557bd58f73314bb4ad85d5a8fd5026
- https://git.kernel.org/stable/c/76ded29d3fcda4928da8849ffc446ea46871c1c2
- https://git.kernel.org/stable/c/2ae38157080616a13a9fe3f0b4b6ec0070aa408a
- https://git.kernel.org/stable/c/471c492890557bd58f73314bb4ad85d5a8fd5026
- https://git.kernel.org/stable/c/76ded29d3fcda4928da8849ffc446ea46871c1c2
Modified: 2025-03-27
CVE-2021-47201
In the Linux kernel, the following vulnerability has been resolved: iavf: free q_vectors before queues in iavf_disable_vf iavf_free_queues() clears adapter->num_active_queues, which iavf_free_q_vectors() relies on, so swap the order of these two function calls in iavf_disable_vf(). This resolves a panic encountered when the interface is disabled and then later brought up again after PF communication is restored.
- https://git.kernel.org/stable/c/78638b47132244e3934dc5dc79f6372d5ce8e98c
- https://git.kernel.org/stable/c/89f22f129696ab53cfbc608e0a2184d0fea46ac1
- https://git.kernel.org/stable/c/926e8c83d4c1c2dac0026637eb0d492df876489e
- https://git.kernel.org/stable/c/9ef6589cac9a8c47f5544ccdf4c498093733bb3f
- https://git.kernel.org/stable/c/78638b47132244e3934dc5dc79f6372d5ce8e98c
- https://git.kernel.org/stable/c/89f22f129696ab53cfbc608e0a2184d0fea46ac1
- https://git.kernel.org/stable/c/926e8c83d4c1c2dac0026637eb0d492df876489e
- https://git.kernel.org/stable/c/9ef6589cac9a8c47f5544ccdf4c498093733bb3f
Modified: 2025-01-14
CVE-2021-47202
In the Linux kernel, the following vulnerability has been resolved: thermal: Fix NULL pointer dereferences in of_thermal_ functions of_parse_thermal_zones() parses the thermal-zones node and registers a thermal_zone device for each subnode. However, if a thermal zone is consuming a thermal sensor and that thermal sensor device hasn't probed yet, an attempt to set trip_point_*_temp for that thermal zone device can cause a NULL pointer dereference. Fix it. console:/sys/class/thermal/thermal_zone87 # echo 120000 > trip_point_0_temp ... Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ... Call trace: of_thermal_set_trip_temp+0x40/0xc4 trip_point_temp_store+0xc0/0x1dc dev_attr_store+0x38/0x88 sysfs_kf_write+0x64/0xc0 kernfs_fop_write_iter+0x108/0x1d0 vfs_write+0x2f4/0x368 ksys_write+0x7c/0xec __arm64_sys_write+0x20/0x30 el0_svc_common.llvm.7279915941325364641+0xbc/0x1bc do_el0_svc+0x28/0xa0 el0_svc+0x14/0x24 el0_sync_handler+0x88/0xec el0_sync+0x1c0/0x200 While at it, fix the possible NULL pointer dereference in other functions as well: of_thermal_get_temp(), of_thermal_set_emul_temp(), of_thermal_get_trend().
- https://git.kernel.org/stable/c/0750f769b95841b34a9fe8c418dd792ff526bf86
- https://git.kernel.org/stable/c/6a315471cb6a07f651e1d3adc8962730f4fcccac
- https://git.kernel.org/stable/c/828f4c31684da94ecf0b44a2cbd35bbede04f0bd
- https://git.kernel.org/stable/c/96cfe05051fd8543cdedd6807ec59a0e6c409195
- https://git.kernel.org/stable/c/ef2590a5305e0b8e9342f84c2214aa478ee7f28e
- https://git.kernel.org/stable/c/0750f769b95841b34a9fe8c418dd792ff526bf86
- https://git.kernel.org/stable/c/6a315471cb6a07f651e1d3adc8962730f4fcccac
- https://git.kernel.org/stable/c/828f4c31684da94ecf0b44a2cbd35bbede04f0bd
- https://git.kernel.org/stable/c/96cfe05051fd8543cdedd6807ec59a0e6c409195
- https://git.kernel.org/stable/c/ef2590a5305e0b8e9342f84c2214aa478ee7f28e
Modified: 2025-03-27
CVE-2021-47203
In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix list_add() corruption in lpfc_drain_txq() When parsing the txq list in lpfc_drain_txq(), the driver attempts to pass the requests to the adapter. If such an attempt fails, a local "fail_msg" string is set and a log message output. The job is then added to a completions list for cancellation. Processing of any further jobs from the txq list continues, but since "fail_msg" remains set, jobs are added to the completions list regardless of whether a wqe was passed to the adapter. If successfully added to txcmplq, jobs are added to both lists resulting in list corruption. Fix by clearing the fail_msg string after adding a job to the completions list. This stops the subsequent jobs from being added to the completions list unless they had an appropriate failure.
- https://git.kernel.org/stable/c/16bcbfb56d759c25665f786e33ec633b9508a08f
- https://git.kernel.org/stable/c/814d3610c4ce86e8cf285b2cdac0057a42e82de5
- https://git.kernel.org/stable/c/99154581b05c8fb22607afb7c3d66c1bace6aa5d
- https://git.kernel.org/stable/c/ad4776b5eb2e58af1226847fcd3b4f6d051674dd
- https://git.kernel.org/stable/c/b291d147d0268e93ad866f8bc820ea14497abc9b
- https://git.kernel.org/stable/c/c097bd5a59162156d9c2077a2f58732ffbaa9fca
- https://git.kernel.org/stable/c/ec70d80a8642900086447ba0cdc79e3f44d42e8f
- https://git.kernel.org/stable/c/f05a0191b90156e539cccc189b9d87ca2a4d9305
- https://git.kernel.org/stable/c/16bcbfb56d759c25665f786e33ec633b9508a08f
- https://git.kernel.org/stable/c/814d3610c4ce86e8cf285b2cdac0057a42e82de5
- https://git.kernel.org/stable/c/99154581b05c8fb22607afb7c3d66c1bace6aa5d
- https://git.kernel.org/stable/c/ad4776b5eb2e58af1226847fcd3b4f6d051674dd
- https://git.kernel.org/stable/c/b291d147d0268e93ad866f8bc820ea14497abc9b
- https://git.kernel.org/stable/c/c097bd5a59162156d9c2077a2f58732ffbaa9fca
- https://git.kernel.org/stable/c/ec70d80a8642900086447ba0cdc79e3f44d42e8f
- https://git.kernel.org/stable/c/f05a0191b90156e539cccc189b9d87ca2a4d9305
Modified: 2025-01-14
CVE-2021-47204
In the Linux kernel, the following vulnerability has been resolved: net: dpaa2-eth: fix use-after-free in dpaa2_eth_remove Access to netdev after free_netdev() will cause use-after-free bug. Move debug log before free_netdev() call to avoid it.
- https://git.kernel.org/stable/c/1c4099dc0d6a01e76e4f7dd98e4b3e0d55d80ad9
- https://git.kernel.org/stable/c/32d4686224744819ddcae58b666c21d2a4ef4c88
- https://git.kernel.org/stable/c/9b5a333272a48c2f8b30add7a874e46e8b26129c
- https://git.kernel.org/stable/c/d74ff10ed2d93dc9b67e99a74b36fb9a83273d8a
- https://git.kernel.org/stable/c/1c4099dc0d6a01e76e4f7dd98e4b3e0d55d80ad9
- https://git.kernel.org/stable/c/32d4686224744819ddcae58b666c21d2a4ef4c88
- https://git.kernel.org/stable/c/9b5a333272a48c2f8b30add7a874e46e8b26129c
- https://git.kernel.org/stable/c/d74ff10ed2d93dc9b67e99a74b36fb9a83273d8a
Modified: 2025-01-07
CVE-2021-47206
In the Linux kernel, the following vulnerability has been resolved: usb: host: ohci-tmio: check return value after calling platform_get_resource() It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value.
- https://git.kernel.org/stable/c/065334f6640d074a1caec2f8b0091467a22f9483
- https://git.kernel.org/stable/c/2474eb7fc3bfbce10f7b8ea431fcffe5dd5f5100
- https://git.kernel.org/stable/c/28e016e02118917e50a667bc72fb80098cf2b460
- https://git.kernel.org/stable/c/2f18f97a1a787154a372c0738f1576f14b693d91
- https://git.kernel.org/stable/c/951b8239fd24678b56c995c5c0456ab12e059d19
- https://git.kernel.org/stable/c/9eff2b2e59fda25051ab36cd1cb5014661df657b
- https://git.kernel.org/stable/c/bb6ed2e05eb6e8619b30fa854f9becd50c11723f
- https://git.kernel.org/stable/c/f98986b7acb4219f95789095eced93ed69d81d35
- https://git.kernel.org/stable/c/065334f6640d074a1caec2f8b0091467a22f9483
- https://git.kernel.org/stable/c/2474eb7fc3bfbce10f7b8ea431fcffe5dd5f5100
- https://git.kernel.org/stable/c/28e016e02118917e50a667bc72fb80098cf2b460
- https://git.kernel.org/stable/c/2f18f97a1a787154a372c0738f1576f14b693d91
- https://git.kernel.org/stable/c/951b8239fd24678b56c995c5c0456ab12e059d19
- https://git.kernel.org/stable/c/9eff2b2e59fda25051ab36cd1cb5014661df657b
- https://git.kernel.org/stable/c/bb6ed2e05eb6e8619b30fa854f9becd50c11723f
- https://git.kernel.org/stable/c/f98986b7acb4219f95789095eced93ed69d81d35
Modified: 2025-01-13
CVE-2021-47207
In the Linux kernel, the following vulnerability has been resolved: ALSA: gus: fix null pointer dereference on pointer block The pointer block return from snd_gf1_dma_next_block could be null, so there is a potential null pointer dereference issue. Fix this by adding a null check before dereference.
- https://git.kernel.org/stable/c/16721797dcef2c7c030ffe73a07f39a65f9323c3
- https://git.kernel.org/stable/c/1ac6cd87d8ddd36c43620f82c4d65b058f725f0f
- https://git.kernel.org/stable/c/3e28e083dcdf03a18a083f8a47b6bb6b1604b5be
- https://git.kernel.org/stable/c/542fa721594a02d2aee0370a764d306ef48d030c
- https://git.kernel.org/stable/c/a0d21bb3279476c777434c40d969ea88ca64f9aa
- https://git.kernel.org/stable/c/ab4c1ebc40f699f48346f634d7b72b9c5193f315
- https://git.kernel.org/stable/c/c6d2cefdd05c4810c416fb8d384b5c377bd977bc
- https://git.kernel.org/stable/c/cb09c760c201f82df83babc92a5ffea0a01807fc
- https://git.kernel.org/stable/c/16721797dcef2c7c030ffe73a07f39a65f9323c3
- https://git.kernel.org/stable/c/1ac6cd87d8ddd36c43620f82c4d65b058f725f0f
- https://git.kernel.org/stable/c/3e28e083dcdf03a18a083f8a47b6bb6b1604b5be
- https://git.kernel.org/stable/c/542fa721594a02d2aee0370a764d306ef48d030c
- https://git.kernel.org/stable/c/a0d21bb3279476c777434c40d969ea88ca64f9aa
- https://git.kernel.org/stable/c/ab4c1ebc40f699f48346f634d7b72b9c5193f315
- https://git.kernel.org/stable/c/c6d2cefdd05c4810c416fb8d384b5c377bd977bc
- https://git.kernel.org/stable/c/cb09c760c201f82df83babc92a5ffea0a01807fc
Modified: 2025-03-27
CVE-2021-47210
In the Linux kernel, the following vulnerability has been resolved: usb: typec: tipd: Remove WARN_ON in tps6598x_block_read Calling tps6598x_block_read with a higher than allowed len can be handled by just returning an error. There's no need to crash systems with panic-on-warn enabled.
- https://git.kernel.org/stable/c/2a897d384513ba7f7ef05611338b9a6ec6aeac00
- https://git.kernel.org/stable/c/2c71811c963b6c310a29455d521d31a7ea6c5b5e
- https://git.kernel.org/stable/c/30dcfcda8992dc42f18e7d35b6a1fa72372d382d
- https://git.kernel.org/stable/c/b7a0a63f3fed57d413bb857de164ea9c3984bc4e
- https://git.kernel.org/stable/c/eff8b7628410cb2eb562ca0d5d1f12e27063733e
- https://git.kernel.org/stable/c/2a897d384513ba7f7ef05611338b9a6ec6aeac00
- https://git.kernel.org/stable/c/2c71811c963b6c310a29455d521d31a7ea6c5b5e
- https://git.kernel.org/stable/c/30dcfcda8992dc42f18e7d35b6a1fa72372d382d
- https://git.kernel.org/stable/c/b7a0a63f3fed57d413bb857de164ea9c3984bc4e
- https://git.kernel.org/stable/c/eff8b7628410cb2eb562ca0d5d1f12e27063733e
Modified: 2025-03-18
CVE-2021-47216
In the Linux kernel, the following vulnerability has been resolved: scsi: advansys: Fix kernel pointer leak Pointers should be printed with %p or %px rather than cast to 'unsigned long' and printed with %lx. Change %lx to %p to print the hashed pointer.
- https://git.kernel.org/stable/c/055eced3edf5b675d12189081303f6285ef26511
- https://git.kernel.org/stable/c/06d7d12efb5c62db9dea15141ae2b322c2719515
- https://git.kernel.org/stable/c/27490ae6a85a70242d80615ca74d0362a820d6a7
- https://git.kernel.org/stable/c/5612287991debe310c914600599bd59511ababfb
- https://git.kernel.org/stable/c/ad19f7046c24f95c674fbea21870479b2b9f5bab
- https://git.kernel.org/stable/c/cc248790bfdcf879e3094fa248c85bf92cdf9dae
- https://git.kernel.org/stable/c/d4996c6eac4c81b8872043e9391563f67f13e406
- https://git.kernel.org/stable/c/f5a0ba4a9b5e70e7b2f767636d26523f9d1ac59d
- https://git.kernel.org/stable/c/055eced3edf5b675d12189081303f6285ef26511
- https://git.kernel.org/stable/c/06d7d12efb5c62db9dea15141ae2b322c2719515
- https://git.kernel.org/stable/c/27490ae6a85a70242d80615ca74d0362a820d6a7
- https://git.kernel.org/stable/c/5612287991debe310c914600599bd59511ababfb
- https://git.kernel.org/stable/c/ad19f7046c24f95c674fbea21870479b2b9f5bab
- https://git.kernel.org/stable/c/cc248790bfdcf879e3094fa248c85bf92cdf9dae
- https://git.kernel.org/stable/c/d4996c6eac4c81b8872043e9391563f67f13e406
- https://git.kernel.org/stable/c/f5a0ba4a9b5e70e7b2f767636d26523f9d1ac59d
Modified: 2025-01-14
CVE-2021-47217
In the Linux kernel, the following vulnerability has been resolved: x86/hyperv: Fix NULL deref in set_hv_tscchange_cb() if Hyper-V setup fails Check for a valid hv_vp_index array prior to derefencing hv_vp_index when setting Hyper-V's TSC change callback. If Hyper-V setup failed in hyperv_init(), the kernel will still report that it's running under Hyper-V, but will have silently disabled nearly all functionality. BUG: kernel NULL pointer dereference, address: 0000000000000010 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP CPU: 4 PID: 1 Comm: swapper/0 Not tainted 5.15.0-rc2+ #75 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:set_hv_tscchange_cb+0x15/0xa0 Code: <8b> 04 82 8b 15 12 17 85 01 48 c1 e0 20 48 0d ee 00 01 00 f6 c6 08 ... Call Trace: kvm_arch_init+0x17c/0x280 kvm_init+0x31/0x330 vmx_init+0xba/0x13a do_one_initcall+0x41/0x1c0 kernel_init_freeable+0x1f2/0x23b kernel_init+0x16/0x120 ret_from_fork+0x22/0x30
- https://git.kernel.org/stable/c/8823ea27fff6084bbb4bc71d15378fae0220b1d8
- https://git.kernel.org/stable/c/9c177eee116cf888276d3748cb176e72562cfd5c
- https://git.kernel.org/stable/c/b0e44dfb4e4c699cca33ede431b8d127e6e8d661
- https://git.kernel.org/stable/c/b20ec58f8a6f4fef32cc71480ddf824584e24743
- https://git.kernel.org/stable/c/daf972118c517b91f74ff1731417feb4270625a4
- https://git.kernel.org/stable/c/8823ea27fff6084bbb4bc71d15378fae0220b1d8
- https://git.kernel.org/stable/c/9c177eee116cf888276d3748cb176e72562cfd5c
- https://git.kernel.org/stable/c/b0e44dfb4e4c699cca33ede431b8d127e6e8d661
- https://git.kernel.org/stable/c/b20ec58f8a6f4fef32cc71480ddf824584e24743
- https://git.kernel.org/stable/c/daf972118c517b91f74ff1731417feb4270625a4
Modified: 2025-01-14
CVE-2021-47218
In the Linux kernel, the following vulnerability has been resolved: selinux: fix NULL-pointer dereference when hashtab allocation fails When the hash table slot array allocation fails in hashtab_init(), h->size is left initialized with a non-zero value, but the h->htable pointer is NULL. This may then cause a NULL pointer dereference, since the policydb code relies on the assumption that even after a failed hashtab_init(), hashtab_map() and hashtab_destroy() can be safely called on it. Yet, these detect an empty hashtab only by looking at the size. Fix this by making sure that hashtab_init() always leaves behind a valid empty hashtab when the allocation fails.
- https://git.kernel.org/stable/c/83c8ab8503adf56bf68dafc7a382f4946c87da79
- https://git.kernel.org/stable/c/b17dd53cac769dd13031b0ca34f90cc65e523fab
- https://git.kernel.org/stable/c/dc27f3c5d10c58069672215787a96b4fae01818b
- https://git.kernel.org/stable/c/83c8ab8503adf56bf68dafc7a382f4946c87da79
- https://git.kernel.org/stable/c/b17dd53cac769dd13031b0ca34f90cc65e523fab
- https://git.kernel.org/stable/c/dc27f3c5d10c58069672215787a96b4fae01818b
Modified: 2025-03-04
CVE-2021-47219
In the Linux kernel, the following vulnerability has been resolved: scsi: scsi_debug: Fix out-of-bound read in resp_report_tgtpgs() The following issue was observed running syzkaller: BUG: KASAN: slab-out-of-bounds in memcpy include/linux/string.h:377 [inline] BUG: KASAN: slab-out-of-bounds in sg_copy_buffer+0x150/0x1c0 lib/scatterlist.c:831 Read of size 2132 at addr ffff8880aea95dc8 by task syz-executor.0/9815 CPU: 0 PID: 9815 Comm: syz-executor.0 Not tainted 4.19.202-00874-gfc0fe04215a9 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xe4/0x14a lib/dump_stack.c:118 print_address_description+0x73/0x280 mm/kasan/report.c:253 kasan_report_error mm/kasan/report.c:352 [inline] kasan_report+0x272/0x370 mm/kasan/report.c:410 memcpy+0x1f/0x50 mm/kasan/kasan.c:302 memcpy include/linux/string.h:377 [inline] sg_copy_buffer+0x150/0x1c0 lib/scatterlist.c:831 fill_from_dev_buffer+0x14f/0x340 drivers/scsi/scsi_debug.c:1021 resp_report_tgtpgs+0x5aa/0x770 drivers/scsi/scsi_debug.c:1772 schedule_resp+0x464/0x12f0 drivers/scsi/scsi_debug.c:4429 scsi_debug_queuecommand+0x467/0x1390 drivers/scsi/scsi_debug.c:5835 scsi_dispatch_cmd+0x3fc/0x9b0 drivers/scsi/scsi_lib.c:1896 scsi_request_fn+0x1042/0x1810 drivers/scsi/scsi_lib.c:2034 __blk_run_queue_uncond block/blk-core.c:464 [inline] __blk_run_queue+0x1a4/0x380 block/blk-core.c:484 blk_execute_rq_nowait+0x1c2/0x2d0 block/blk-exec.c:78 sg_common_write.isra.19+0xd74/0x1dc0 drivers/scsi/sg.c:847 sg_write.part.23+0x6e0/0xd00 drivers/scsi/sg.c:716 sg_write+0x64/0xa0 drivers/scsi/sg.c:622 __vfs_write+0xed/0x690 fs/read_write.c:485 kill_bdev:block_device:00000000e138492c vfs_write+0x184/0x4c0 fs/read_write.c:549 ksys_write+0x107/0x240 fs/read_write.c:599 do_syscall_64+0xc2/0x560 arch/x86/entry/common.c:293 entry_SYSCALL_64_after_hwframe+0x49/0xbe We get 'alen' from command its type is int. If userspace passes a large length we will get a negative 'alen'. Switch n, alen, and rlen to u32.
- https://git.kernel.org/stable/c/66523553fa62c7878fc5441dc4e82be71934eb77
- https://git.kernel.org/stable/c/8440377e1a5644779b4c8d013aa2a917f5fc83c3
- https://git.kernel.org/stable/c/f347c26836c270199de1599c3cd466bb7747caa9
- https://git.kernel.org/stable/c/66523553fa62c7878fc5441dc4e82be71934eb77
- https://git.kernel.org/stable/c/8440377e1a5644779b4c8d013aa2a917f5fc83c3
- https://git.kernel.org/stable/c/f347c26836c270199de1599c3cd466bb7747caa9
Modified: 2025-01-06
CVE-2021-47499
In the Linux kernel, the following vulnerability has been resolved: iio: accel: kxcjk-1013: Fix possible memory leak in probe and remove When ACPI type is ACPI_SMO8500, the data->dready_trig will not be set, the memory allocated by iio_triggered_buffer_setup() will not be freed, and cause memory leak as follows: unreferenced object 0xffff888009551400 (size 512): comm "i2c-SMO8500-125", pid 911, jiffies 4294911787 (age 83.852s) hex dump (first 32 bytes): 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 20 e2 e5 c0 ff ff ff ff ........ ....... backtrace: [<0000000041ce75ee>] kmem_cache_alloc_trace+0x16d/0x360 [<000000000aeb17b0>] iio_kfifo_allocate+0x41/0x130 [kfifo_buf] [<000000004b40c1f5>] iio_triggered_buffer_setup_ext+0x2c/0x210 [industrialio_triggered_buffer] [<000000004375b15f>] kxcjk1013_probe+0x10c3/0x1d81 [kxcjk_1013] Fix it by remove data->dready_trig condition in probe and remove.
- https://git.kernel.org/stable/c/14508fe13b1c578b3d2ba574f1d48b351975860c
- https://git.kernel.org/stable/c/3899700ddacbf7aaafadf44464fff3ff0d4e3307
- https://git.kernel.org/stable/c/60a55b9d91ba99eb8cf015bc46dc2de05e168a15
- https://git.kernel.org/stable/c/70c9774e180d151abaab358108e3510a8e615215
- https://git.kernel.org/stable/c/8c163a14277115ca962103910ab4cce55e862ffb
- https://git.kernel.org/stable/c/8c1d43f3a3fc7184c42d7398bdf59a2a2903e4fc
- https://git.kernel.org/stable/c/a3730f74159ad00a28960c0efe2a931fe6fe6b45
- https://git.kernel.org/stable/c/ee86d0bad80bdcd11a87e188a596727f41b62320
- https://git.kernel.org/stable/c/14508fe13b1c578b3d2ba574f1d48b351975860c
- https://git.kernel.org/stable/c/3899700ddacbf7aaafadf44464fff3ff0d4e3307
- https://git.kernel.org/stable/c/60a55b9d91ba99eb8cf015bc46dc2de05e168a15
- https://git.kernel.org/stable/c/70c9774e180d151abaab358108e3510a8e615215
- https://git.kernel.org/stable/c/8c163a14277115ca962103910ab4cce55e862ffb
- https://git.kernel.org/stable/c/8c1d43f3a3fc7184c42d7398bdf59a2a2903e4fc
- https://git.kernel.org/stable/c/a3730f74159ad00a28960c0efe2a931fe6fe6b45
- https://git.kernel.org/stable/c/ee86d0bad80bdcd11a87e188a596727f41b62320
Modified: 2025-01-06
CVE-2021-47500
In the Linux kernel, the following vulnerability has been resolved: iio: mma8452: Fix trigger reference couting The mma8452 driver directly assigns a trigger to the struct iio_dev. The IIO core when done using this trigger will call `iio_trigger_put()` to drop the reference count by 1. Without the matching `iio_trigger_get()` in the driver the reference count can reach 0 too early, the trigger gets freed while still in use and a use-after-free occurs. Fix this by getting a reference to the trigger before assigning it to the IIO device.
- https://git.kernel.org/stable/c/094d513b78b1714113bc016684b8142382e071ba
- https://git.kernel.org/stable/c/794c0898f6bf39a458655d5fb4af70ec43a5cfcb
- https://git.kernel.org/stable/c/acf0088ac073ca6e7f4cad6acac112177e08df5e
- https://git.kernel.org/stable/c/c43517071dfc9fce34f8f69dbb98a86017f6b739
- https://git.kernel.org/stable/c/cd0082235783f814241a1c9483fb89e405f4f892
- https://git.kernel.org/stable/c/db12d95085367de8b0223929d1332731024441f1
- https://git.kernel.org/stable/c/f5deab10ced368c807866283f8b79144c4823be8
- https://git.kernel.org/stable/c/fb75cc4740d81264cd5bcb0e17d961d018a8be96
- https://git.kernel.org/stable/c/094d513b78b1714113bc016684b8142382e071ba
- https://git.kernel.org/stable/c/794c0898f6bf39a458655d5fb4af70ec43a5cfcb
- https://git.kernel.org/stable/c/acf0088ac073ca6e7f4cad6acac112177e08df5e
- https://git.kernel.org/stable/c/c43517071dfc9fce34f8f69dbb98a86017f6b739
- https://git.kernel.org/stable/c/cd0082235783f814241a1c9483fb89e405f4f892
- https://git.kernel.org/stable/c/db12d95085367de8b0223929d1332731024441f1
- https://git.kernel.org/stable/c/f5deab10ced368c807866283f8b79144c4823be8
- https://git.kernel.org/stable/c/fb75cc4740d81264cd5bcb0e17d961d018a8be96
Modified: 2025-01-06
CVE-2021-47501
In the Linux kernel, the following vulnerability has been resolved: i40e: Fix NULL pointer dereference in i40e_dbg_dump_desc When trying to dump VFs VSI RX/TX descriptors using debugfs there was a crash due to NULL pointer dereference in i40e_dbg_dump_desc. Added a check to i40e_dbg_dump_desc that checks if VSI type is correct for dumping RX/TX descriptors.
- https://git.kernel.org/stable/c/16431e442db248ecd8aa9457cf0a656f1885f56e
- https://git.kernel.org/stable/c/23ec111bf3549aae37140330c31a16abfc172421
- https://git.kernel.org/stable/c/e5b7fb2198abc50058f1a29c395b004f76ab1c83
- https://git.kernel.org/stable/c/16431e442db248ecd8aa9457cf0a656f1885f56e
- https://git.kernel.org/stable/c/23ec111bf3549aae37140330c31a16abfc172421
- https://git.kernel.org/stable/c/e5b7fb2198abc50058f1a29c395b004f76ab1c83
Modified: 2025-09-29
CVE-2021-47502
In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: wcd934x: handle channel mappping list correctly Currently each channel is added as list to dai channel list, however there is danger of adding same channel to multiple dai channel list which endups corrupting the other list where its already added. This patch ensures that the channel is actually free before adding to the dai channel list and also ensures that the channel is on the list before deleting it. This check was missing previously, and we did not hit this issue as we were testing very simple usecases with sequence of amixer commands.
- https://git.kernel.org/stable/c/1089dac26c6b4b833323ae6c0ceab29fb30ede72
- https://git.kernel.org/stable/c/23ba28616d3063bd4c4953598ed5e439ca891101
- https://git.kernel.org/stable/c/339ffb5b56005582aacc860524d2d208604049d1
- https://git.kernel.org/stable/c/1089dac26c6b4b833323ae6c0ceab29fb30ede72
- https://git.kernel.org/stable/c/23ba28616d3063bd4c4953598ed5e439ca891101
- https://git.kernel.org/stable/c/339ffb5b56005582aacc860524d2d208604049d1
Modified: 2025-04-01
CVE-2021-47503
In the Linux kernel, the following vulnerability has been resolved: scsi: pm80xx: Do not call scsi_remove_host() in pm8001_alloc() Calling scsi_remove_host() before scsi_add_host() results in a crash: BUG: kernel NULL pointer dereference, address: 0000000000000108 RIP: 0010:device_del+0x63/0x440 Call Trace: device_unregister+0x17/0x60 scsi_remove_host+0xee/0x2a0 pm8001_pci_probe+0x6ef/0x1b90 [pm80xx] local_pci_probe+0x3f/0x90 We cannot call scsi_remove_host() in pm8001_alloc() because scsi_add_host() has not been called yet at that point in time. Function call tree: pm8001_pci_probe() | `- pm8001_pci_alloc() | | | `- pm8001_alloc() | | | `- scsi_remove_host() | `- scsi_add_host()
- https://git.kernel.org/stable/c/1e434d2687e8bc0b3cdc9dd093c0e9047c0b4add
- https://git.kernel.org/stable/c/653926205741add87a6cf452e21950eebc6ac10b
- https://git.kernel.org/stable/c/f8dccc1bdea7e21b5ec06c957aef8831c772661c
- https://git.kernel.org/stable/c/1e434d2687e8bc0b3cdc9dd093c0e9047c0b4add
- https://git.kernel.org/stable/c/653926205741add87a6cf452e21950eebc6ac10b
- https://git.kernel.org/stable/c/f8dccc1bdea7e21b5ec06c957aef8831c772661c
Modified: 2025-01-10
CVE-2021-47505
In the Linux kernel, the following vulnerability has been resolved:
aio: fix use-after-free due to missing POLLFREE handling
signalfd_poll() and binder_poll() are special in that they use a
waitqueue whose lifetime is the current task, rather than the struct
file as is normally the case. This is okay for blocking polls, since a
blocking poll occurs within one task; however, non-blocking polls
require another solution. This solution is for the queue to be cleared
before it is freed, by sending a POLLFREE notification to all waiters.
Unfortunately, only eventpoll handles POLLFREE. A second type of
non-blocking poll, aio poll, was added in kernel v4.18, and it doesn't
handle POLLFREE. This allows a use-after-free to occur if a signalfd or
binder fd is polled with aio poll, and the waitqueue gets freed.
Fix this by making aio poll handle POLLFREE.
A patch by Ramji Jiyani
- https://git.kernel.org/stable/c/321fba81ec034f88aea4898993c1bf15605c023f
- https://git.kernel.org/stable/c/4105e6a128e8a98455dfc9e6dbb2ab0c33c4497f
- https://git.kernel.org/stable/c/47ffefd88abfffe8a040bcc1dd0554d4ea6f7689
- https://git.kernel.org/stable/c/50252e4b5e989ce64555c7aef7516bdefc2fea72
- https://git.kernel.org/stable/c/60d311f9e6381d779d7d53371f87285698ecee24
- https://git.kernel.org/stable/c/321fba81ec034f88aea4898993c1bf15605c023f
- https://git.kernel.org/stable/c/4105e6a128e8a98455dfc9e6dbb2ab0c33c4497f
- https://git.kernel.org/stable/c/47ffefd88abfffe8a040bcc1dd0554d4ea6f7689
- https://git.kernel.org/stable/c/50252e4b5e989ce64555c7aef7516bdefc2fea72
- https://git.kernel.org/stable/c/60d311f9e6381d779d7d53371f87285698ecee24
Modified: 2025-01-06
CVE-2021-47506
In the Linux kernel, the following vulnerability has been resolved: nfsd: fix use-after-free due to delegation race A delegation break could arrive as soon as we've called vfs_setlease. A delegation break runs a callback which immediately (in nfsd4_cb_recall_prepare) adds the delegation to del_recall_lru. If we then exit nfs4_set_delegation without hashing the delegation, it will be freed as soon as the callback is done with it, without ever being removed from del_recall_lru. Symptoms show up later as use-after-free or list corruption warnings, usually in the laundromat thread. I suspect aba2072f4523 "nfsd: grant read delegations to clients holding writes" made this bug easier to hit, but I looked as far back as v3.0 and it looks to me it already had the same problem. So I'm not sure where the bug was introduced; it may have been there from the beginning.
- https://git.kernel.org/stable/c/04a8d07f3d58308b92630045560799a3faa3ebce
- https://git.kernel.org/stable/c/148c816f10fd11df27ca6a9b3238cdd42fa72cd3
- https://git.kernel.org/stable/c/2becaa990b93cbd2928292c0b669d3abb6cf06d4
- https://git.kernel.org/stable/c/33645d3e22720cac1e4548f8fef57bf0649536ee
- https://git.kernel.org/stable/c/348714018139c39533c55661a0c7c990671396b4
- https://git.kernel.org/stable/c/548ec0805c399c65ed66c6641be467f717833ab5
- https://git.kernel.org/stable/c/e0759696de6851d7536efddfdd2dfed4c4df1f09
- https://git.kernel.org/stable/c/eeb0711801f5e19ef654371b627682aed3b11373
- https://git.kernel.org/stable/c/04a8d07f3d58308b92630045560799a3faa3ebce
- https://git.kernel.org/stable/c/148c816f10fd11df27ca6a9b3238cdd42fa72cd3
- https://git.kernel.org/stable/c/2becaa990b93cbd2928292c0b669d3abb6cf06d4
- https://git.kernel.org/stable/c/33645d3e22720cac1e4548f8fef57bf0649536ee
- https://git.kernel.org/stable/c/348714018139c39533c55661a0c7c990671396b4
- https://git.kernel.org/stable/c/548ec0805c399c65ed66c6641be467f717833ab5
- https://git.kernel.org/stable/c/e0759696de6851d7536efddfdd2dfed4c4df1f09
- https://git.kernel.org/stable/c/eeb0711801f5e19ef654371b627682aed3b11373
Modified: 2025-09-24
CVE-2021-47507
In the Linux kernel, the following vulnerability has been resolved: nfsd: Fix nsfd startup race (again) Commit bd5ae9288d64 ("nfsd: register pernet ops last, unregister first") has re-opened rpc_pipefs_event() race against nfsd_net_id registration (register_pernet_subsys()) which has been fixed by commit bb7ffbf29e76 ("nfsd: fix nsfd startup race triggering BUG_ON"). Restore the order of register_pernet_subsys() vs register_cld_notifier(). Add WARN_ON() to prevent a future regression. Crash info: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000012 CPU: 8 PID: 345 Comm: mount Not tainted 5.4.144-... #1 pc : rpc_pipefs_event+0x54/0x120 [nfsd] lr : rpc_pipefs_event+0x48/0x120 [nfsd] Call trace: rpc_pipefs_event+0x54/0x120 [nfsd] blocking_notifier_call_chain rpc_fill_super get_tree_keyed rpc_fs_get_tree vfs_get_tree do_mount ksys_mount __arm64_sys_mount el0_svc_handler el0_svc
- https://git.kernel.org/stable/c/8bf902fee5893cfc2f04a698abab47629699ae9a
- https://git.kernel.org/stable/c/b10252c7ae9c9d7c90552f88b544a44ee773af64
- https://git.kernel.org/stable/c/c520943a00ad5015704969ad3304c956bcd49d25
- https://git.kernel.org/stable/c/f5734b1714ca355703e9ea8fb61d04beff1790b9
- https://git.kernel.org/stable/c/8bf902fee5893cfc2f04a698abab47629699ae9a
- https://git.kernel.org/stable/c/b10252c7ae9c9d7c90552f88b544a44ee773af64
- https://git.kernel.org/stable/c/c520943a00ad5015704969ad3304c956bcd49d25
- https://git.kernel.org/stable/c/f5734b1714ca355703e9ea8fb61d04beff1790b9
Modified: 2025-09-29
CVE-2021-47509
In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: oss: Limit the period size to 16MB Set the practical limit to the period size (the fragment shift in OSS) instead of a full 31bit; a too large value could lead to the exhaust of memory as we allocate temporary buffers of the period size, too. As of this patch, we set to 16MB limit, which should cover all use cases.
- https://git.kernel.org/stable/c/2e54cf6794bf82a54aaefc78da13819aea9cd28a
- https://git.kernel.org/stable/c/35a3e511032146941085f87dd9fb5b82ea5c00a2
- https://git.kernel.org/stable/c/76f19e4cbb548e28547f8c328aa0bfb3a10222d3
- https://git.kernel.org/stable/c/8839c8c0f77ab8fc0463f4ab8b37fca3f70677c2
- https://git.kernel.org/stable/c/ad45babf7886e7a212ee1d5eda9ef49f696db43c
- https://git.kernel.org/stable/c/b02a41eebcc36d4f07196780f2e165ca2c499257
- https://git.kernel.org/stable/c/be55f306396cd62c6889286a7194fd8b53363aeb
- https://git.kernel.org/stable/c/d1bb703ad050de9095f10b2d3416c32921ac6bcc
- https://git.kernel.org/stable/c/2e54cf6794bf82a54aaefc78da13819aea9cd28a
- https://git.kernel.org/stable/c/35a3e511032146941085f87dd9fb5b82ea5c00a2
- https://git.kernel.org/stable/c/76f19e4cbb548e28547f8c328aa0bfb3a10222d3
- https://git.kernel.org/stable/c/8839c8c0f77ab8fc0463f4ab8b37fca3f70677c2
- https://git.kernel.org/stable/c/ad45babf7886e7a212ee1d5eda9ef49f696db43c
- https://git.kernel.org/stable/c/b02a41eebcc36d4f07196780f2e165ca2c499257
- https://git.kernel.org/stable/c/be55f306396cd62c6889286a7194fd8b53363aeb
- https://git.kernel.org/stable/c/d1bb703ad050de9095f10b2d3416c32921ac6bcc
Modified: 2025-09-29
CVE-2021-47511
In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: oss: Fix negative period/buffer sizes The period size calculation in OSS layer may receive a negative value as an error, but the code there assumes only the positive values and handle them with size_t. Due to that, a too big value may be passed to the lower layers. This patch changes the code to handle with ssize_t and adds the proper error checks appropriately.
- https://git.kernel.org/stable/c/00a860678098fcd9fa8db2b5fb9d2ddf4776d4cc
- https://git.kernel.org/stable/c/02b2b691b77cd7b951fa7b6c9d44d4e472cdc823
- https://git.kernel.org/stable/c/502e1146873d870f87da3b8f93d6bf2de5f38d0c
- https://git.kernel.org/stable/c/8af815ab052eaf74addbbfb556d63ce2137c0e1b
- https://git.kernel.org/stable/c/9d2479c960875ca1239bcb899f386970c13d9cfe
- https://git.kernel.org/stable/c/be8869d388593e57223ad39297c8e54be632f2f2
- https://git.kernel.org/stable/c/f12c8a7515f641885677960af450082569a87243
- https://git.kernel.org/stable/c/f96c0959c1ee92adc911c10d6ec209af50105049
- https://git.kernel.org/stable/c/00a860678098fcd9fa8db2b5fb9d2ddf4776d4cc
- https://git.kernel.org/stable/c/02b2b691b77cd7b951fa7b6c9d44d4e472cdc823
- https://git.kernel.org/stable/c/502e1146873d870f87da3b8f93d6bf2de5f38d0c
- https://git.kernel.org/stable/c/8af815ab052eaf74addbbfb556d63ce2137c0e1b
- https://git.kernel.org/stable/c/9d2479c960875ca1239bcb899f386970c13d9cfe
- https://git.kernel.org/stable/c/be8869d388593e57223ad39297c8e54be632f2f2
- https://git.kernel.org/stable/c/f12c8a7515f641885677960af450082569a87243
- https://git.kernel.org/stable/c/f96c0959c1ee92adc911c10d6ec209af50105049
Modified: 2025-01-06
CVE-2021-47512
In the Linux kernel, the following vulnerability has been resolved:
net/sched: fq_pie: prevent dismantle issue
For some reason, fq_pie_destroy() did not copy
working code from pie_destroy() and other qdiscs,
thus causing elusive bug.
Before calling del_timer_sync(&q->adapt_timer),
we need to ensure timer will not rearm itself.
rcu: INFO: rcu_preempt self-detected stall on CPU
rcu: 0-....: (4416 ticks this GP) idle=60d/1/0x4000000000000000 softirq=10433/10434 fqs=2579
(t=10501 jiffies g=13085 q=3989)
NMI backtrace for cpu 0
CPU: 0 PID: 13 Comm: ksoftirqd/0 Not tainted 5.16.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
- https://git.kernel.org/stable/c/2a51edaf5cc563574878b93d7ef3d5955dda7030
- https://git.kernel.org/stable/c/61c2402665f1e10c5742033fce18392e369931d7
- https://git.kernel.org/stable/c/d86216dfda7c98375f809e26a30bfdaaba21d46e
- https://git.kernel.org/stable/c/2a51edaf5cc563574878b93d7ef3d5955dda7030
- https://git.kernel.org/stable/c/61c2402665f1e10c5742033fce18392e369931d7
- https://git.kernel.org/stable/c/d86216dfda7c98375f809e26a30bfdaaba21d46e
Modified: 2025-01-06
CVE-2021-47514
In the Linux kernel, the following vulnerability has been resolved: devlink: fix netns refcount leak in devlink_nl_cmd_reload() While preparing my patch series adding netns refcount tracking, I spotted bugs in devlink_nl_cmd_reload() Some error paths forgot to release a refcount on a netns. To fix this, we can reduce the scope of get_net()/put_net() section around the call to devlink_reload().
- https://git.kernel.org/stable/c/4b7e90672af8e0c78205db006f1b0a20ebd07f5f
- https://git.kernel.org/stable/c/4dbb0dad8e63fcd0b5a117c2861d2abe7ff5f186
- https://git.kernel.org/stable/c/fe30b70ca84da9c4aca85c03ad86e7a9b89c5ded
- https://git.kernel.org/stable/c/4b7e90672af8e0c78205db006f1b0a20ebd07f5f
- https://git.kernel.org/stable/c/4dbb0dad8e63fcd0b5a117c2861d2abe7ff5f186
- https://git.kernel.org/stable/c/fe30b70ca84da9c4aca85c03ad86e7a9b89c5ded
Modified: 2025-09-24
CVE-2021-47515
In the Linux kernel, the following vulnerability has been resolved: seg6: fix the iif in the IPv6 socket control block When an IPv4 packet is received, the ip_rcv_core(...) sets the receiving interface index into the IPv4 socket control block (v5.16-rc4, net/ipv4/ip_input.c line 510): IPCB(skb)->iif = skb->skb_iif; If that IPv4 packet is meant to be encapsulated in an outer IPv6+SRH header, the seg6_do_srh_encap(...) performs the required encapsulation. In this case, the seg6_do_srh_encap function clears the IPv6 socket control block (v5.16-rc4 net/ipv6/seg6_iptunnel.c line 163): memset(IP6CB(skb), 0, sizeof(*IP6CB(skb))); The memset(...) was introduced in commit ef489749aae5 ("ipv6: sr: clear IP6CB(skb) on SRH ip4ip6 encapsulation") a long time ago (2019-01-29). Since the IPv6 socket control block and the IPv4 socket control block share the same memory area (skb->cb), the receiving interface index info is lost (IP6CB(skb)->iif is set to zero). As a side effect, that condition triggers a NULL pointer dereference if commit 0857d6f8c759 ("ipv6: When forwarding count rx stats on the orig netdev") is applied. To fix that issue, we set the IP6CB(skb)->iif with the index of the receiving interface once again.
- https://git.kernel.org/stable/c/6431e71093f3da586a00c6d931481ffb0dc2db0e
- https://git.kernel.org/stable/c/666521b3852d2b2f52d570f9122b1e4b50d96831
- https://git.kernel.org/stable/c/98adb2bbfa407c9290bda299d4c6f7a1c4ebd5e1
- https://git.kernel.org/stable/c/ae68d93354e5bf5191ee673982251864ea24dd5c
- https://git.kernel.org/stable/c/b16d412e5f79734033df04e97d7ea2f50a8e9fe3
- https://git.kernel.org/stable/c/ef8804e47c0a44ae106ead1740408af5ea6c6ee9
- https://git.kernel.org/stable/c/6431e71093f3da586a00c6d931481ffb0dc2db0e
- https://git.kernel.org/stable/c/666521b3852d2b2f52d570f9122b1e4b50d96831
- https://git.kernel.org/stable/c/98adb2bbfa407c9290bda299d4c6f7a1c4ebd5e1
- https://git.kernel.org/stable/c/ae68d93354e5bf5191ee673982251864ea24dd5c
- https://git.kernel.org/stable/c/b16d412e5f79734033df04e97d7ea2f50a8e9fe3
- https://git.kernel.org/stable/c/ef8804e47c0a44ae106ead1740408af5ea6c6ee9
Modified: 2024-11-21
CVE-2021-47516
In the Linux kernel, the following vulnerability has been resolved: nfp: Fix memory leak in nfp_cpp_area_cache_add() In line 800 (#1), nfp_cpp_area_alloc() allocates and initializes a CPP area structure. But in line 807 (#2), when the cache is allocated failed, this CPP area structure is not freed, which will result in memory leak. We can fix it by freeing the CPP area when the cache is allocated failed (#2). 792 int nfp_cpp_area_cache_add(struct nfp_cpp *cpp, size_t size) 793 { 794 struct nfp_cpp_area_cache *cache; 795 struct nfp_cpp_area *area; 800 area = nfp_cpp_area_alloc(cpp, NFP_CPP_ID(7, NFP_CPP_ACTION_RW, 0), 801 0, size); // #1: allocates and initializes 802 if (!area) 803 return -ENOMEM; 805 cache = kzalloc(sizeof(*cache), GFP_KERNEL); 806 if (!cache) 807 return -ENOMEM; // #2: missing free 817 return 0; 818 }
- https://git.kernel.org/stable/c/2e0e072e62fdaf7816220af08e05c020f0fcb77a
- https://git.kernel.org/stable/c/3e93abcdcec0436fbf0b6a88ae806902426895a2
- https://git.kernel.org/stable/c/484069b5de9d223cc1c64c6f80389a99cfef51f1
- https://git.kernel.org/stable/c/c56c96303e9289cc34716b1179597b6f470833de
- https://git.kernel.org/stable/c/eb51f639ef3fd5498b7def290ed8681b6aadd9a7
- https://git.kernel.org/stable/c/f707820c09239d6f67699d9b2ff57863cc7905b0
- https://git.kernel.org/stable/c/2e0e072e62fdaf7816220af08e05c020f0fcb77a
- https://git.kernel.org/stable/c/3e93abcdcec0436fbf0b6a88ae806902426895a2
- https://git.kernel.org/stable/c/484069b5de9d223cc1c64c6f80389a99cfef51f1
- https://git.kernel.org/stable/c/c56c96303e9289cc34716b1179597b6f470833de
- https://git.kernel.org/stable/c/eb51f639ef3fd5498b7def290ed8681b6aadd9a7
- https://git.kernel.org/stable/c/f707820c09239d6f67699d9b2ff57863cc7905b0
Modified: 2024-11-21
CVE-2021-47518
In the Linux kernel, the following vulnerability has been resolved: nfc: fix potential NULL pointer deref in nfc_genl_dump_ses_done The done() netlink callback nfc_genl_dump_ses_done() should check if received argument is non-NULL, because its allocation could fail earlier in dumpit() (nfc_genl_dump_ses()).
- https://git.kernel.org/stable/c/3b861a40325eac9c4c13b6c53874ad90617e944d
- https://git.kernel.org/stable/c/48fcd08fdbe05e35b650a252ec2a2d96057a1c7a
- https://git.kernel.org/stable/c/4cd8371a234d051f9c9557fcbb1f8c523b1c0d10
- https://git.kernel.org/stable/c/69bb79a8f5bb9f436b6f1434ca9742591b7bbe18
- https://git.kernel.org/stable/c/811a7576747760bcaf60502f096d1e6e91d566fa
- https://git.kernel.org/stable/c/83ea620a1be840bf05089a5061fb8323ca42f38c
- https://git.kernel.org/stable/c/87cdb8789c38e44ae5454aafe277997c950d00ed
- https://git.kernel.org/stable/c/fae9705d281091254d4a81fa2da9d22346097dca
- https://git.kernel.org/stable/c/3b861a40325eac9c4c13b6c53874ad90617e944d
- https://git.kernel.org/stable/c/48fcd08fdbe05e35b650a252ec2a2d96057a1c7a
- https://git.kernel.org/stable/c/4cd8371a234d051f9c9557fcbb1f8c523b1c0d10
- https://git.kernel.org/stable/c/69bb79a8f5bb9f436b6f1434ca9742591b7bbe18
- https://git.kernel.org/stable/c/811a7576747760bcaf60502f096d1e6e91d566fa
- https://git.kernel.org/stable/c/83ea620a1be840bf05089a5061fb8323ca42f38c
- https://git.kernel.org/stable/c/87cdb8789c38e44ae5454aafe277997c950d00ed
- https://git.kernel.org/stable/c/fae9705d281091254d4a81fa2da9d22346097dca
Modified: 2024-11-21
CVE-2021-47520
In the Linux kernel, the following vulnerability has been resolved: can: pch_can: pch_can_rx_normal: fix use after free After calling netif_receive_skb(skb), dereferencing skb is unsafe. Especially, the can_frame cf which aliases skb memory is dereferenced just after the call netif_receive_skb(skb). Reordering the lines solves the issue.
- https://git.kernel.org/stable/c/3a3c46e2eff0577454860a203be1a8295f4acb76
- https://git.kernel.org/stable/c/3e193ef4e0a3f5bf92ede83ef214cb09d01b00aa
- https://git.kernel.org/stable/c/6c73fc931658d8cbc8a1714b326cb31eb71d16a7
- https://git.kernel.org/stable/c/703dde112021c93d6e89443c070e7dbd4dea612e
- https://git.kernel.org/stable/c/94cddf1e9227a171b27292509d59691819c458db
- https://git.kernel.org/stable/c/abb4eff3dcd2e583060082a18a8dbf31f02689d4
- https://git.kernel.org/stable/c/affbad02bf80380a7403885b9fe4a1587d1bb4f3
- https://git.kernel.org/stable/c/bafe343a885c70dddf358379cf0b2a1c07355d8d
- https://git.kernel.org/stable/c/3a3c46e2eff0577454860a203be1a8295f4acb76
- https://git.kernel.org/stable/c/3e193ef4e0a3f5bf92ede83ef214cb09d01b00aa
- https://git.kernel.org/stable/c/6c73fc931658d8cbc8a1714b326cb31eb71d16a7
- https://git.kernel.org/stable/c/703dde112021c93d6e89443c070e7dbd4dea612e
- https://git.kernel.org/stable/c/94cddf1e9227a171b27292509d59691819c458db
- https://git.kernel.org/stable/c/abb4eff3dcd2e583060082a18a8dbf31f02689d4
- https://git.kernel.org/stable/c/affbad02bf80380a7403885b9fe4a1587d1bb4f3
- https://git.kernel.org/stable/c/bafe343a885c70dddf358379cf0b2a1c07355d8d
Modified: 2024-11-21
CVE-2021-47521
In the Linux kernel, the following vulnerability has been resolved: can: sja1000: fix use after free in ems_pcmcia_add_card() If the last channel is not available then "dev" is freed. Fortunately, we can just use "pdev->irq" instead. Also we should check if at least one channel was set up.
- https://git.kernel.org/stable/c/1a295fea90e1acbe80c6d4940f5ff856edcd6bec
- https://git.kernel.org/stable/c/1dd5b819f7e406dc15bbc7670596ff25261aaa2a
- https://git.kernel.org/stable/c/3ec6ca6b1a8e64389f0212b5a1b0f6fed1909e45
- https://git.kernel.org/stable/c/474f9a8534f5f89841240a7e978bafd6e1e039ce
- https://git.kernel.org/stable/c/923f4dc5df679f678e121c20bf2fd70f7bf3e288
- https://git.kernel.org/stable/c/c8718026ba287168ff9ad0ccc4f9a413062cba36
- https://git.kernel.org/stable/c/cbd86110546f7f730a1f5d7de56c944a336c15c4
- https://git.kernel.org/stable/c/ccf070183e4655824936c0f96c4a2bcca93419aa
- https://git.kernel.org/stable/c/1a295fea90e1acbe80c6d4940f5ff856edcd6bec
- https://git.kernel.org/stable/c/1dd5b819f7e406dc15bbc7670596ff25261aaa2a
- https://git.kernel.org/stable/c/3ec6ca6b1a8e64389f0212b5a1b0f6fed1909e45
- https://git.kernel.org/stable/c/474f9a8534f5f89841240a7e978bafd6e1e039ce
- https://git.kernel.org/stable/c/923f4dc5df679f678e121c20bf2fd70f7bf3e288
- https://git.kernel.org/stable/c/c8718026ba287168ff9ad0ccc4f9a413062cba36
- https://git.kernel.org/stable/c/cbd86110546f7f730a1f5d7de56c944a336c15c4
- https://git.kernel.org/stable/c/ccf070183e4655824936c0f96c4a2bcca93419aa
Modified: 2024-11-21
CVE-2021-47522
In the Linux kernel, the following vulnerability has been resolved: HID: bigbenff: prevent null pointer dereference When emulating the device through uhid, there is a chance we don't have output reports and so report_field is null.
- https://git.kernel.org/stable/c/58f15f5ae7786c824868f3a7e093859b74669ce7
- https://git.kernel.org/stable/c/6272b17001e6fdcf7b4a16206287010a1523fa6e
- https://git.kernel.org/stable/c/8e0ceff632f48175ec7fb4706129c55ca8a7c7bd
- https://git.kernel.org/stable/c/918aa1ef104d286d16b9e7ef139a463ac7a296f0
- https://git.kernel.org/stable/c/58f15f5ae7786c824868f3a7e093859b74669ce7
- https://git.kernel.org/stable/c/6272b17001e6fdcf7b4a16206287010a1523fa6e
- https://git.kernel.org/stable/c/8e0ceff632f48175ec7fb4706129c55ca8a7c7bd
- https://git.kernel.org/stable/c/918aa1ef104d286d16b9e7ef139a463ac7a296f0
Modified: 2025-09-24
CVE-2021-47523
In the Linux kernel, the following vulnerability has been resolved: IB/hfi1: Fix leak of rcvhdrtail_dummy_kvaddr This buffer is currently allocated in hfi1_init(): if (reinit) ret = init_after_reset(dd); else ret = loadtime_init(dd); if (ret) goto done; /* allocate dummy tail memory for all receive contexts */ dd->rcvhdrtail_dummy_kvaddr = dma_alloc_coherent(&dd->pcidev->dev, sizeof(u64), &dd->rcvhdrtail_dummy_dma, GFP_KERNEL); if (!dd->rcvhdrtail_dummy_kvaddr) { dd_dev_err(dd, "cannot allocate dummy tail memory\n"); ret = -ENOMEM; goto done; } The reinit triggered path will overwrite the old allocation and leak it. Fix by moving the allocation to hfi1_alloc_devdata() and the deallocation to hfi1_free_devdata().
- https://git.kernel.org/stable/c/2c08271f4ed0e24633b3f81ceff61052b9d45efc
- https://git.kernel.org/stable/c/60a8b5a1611b4a26de4839ab9c1fc2a9cf3e17c1
- https://git.kernel.org/stable/c/834d0fb978643eaf09da425de197cc16a7c2761b
- https://git.kernel.org/stable/c/2c08271f4ed0e24633b3f81ceff61052b9d45efc
- https://git.kernel.org/stable/c/60a8b5a1611b4a26de4839ab9c1fc2a9cf3e17c1
- https://git.kernel.org/stable/c/834d0fb978643eaf09da425de197cc16a7c2761b
Modified: 2025-09-24
CVE-2021-47527
In the Linux kernel, the following vulnerability has been resolved: serial: core: fix transmit-buffer reset and memleak Commit 761ed4a94582 ("tty: serial_core: convert uart_close to use tty_port_close") converted serial core to use tty_port_close() but failed to notice that the transmit buffer still needs to be freed on final close. Not freeing the transmit buffer means that the buffer is no longer cleared on next open so that any ioctl() waiting for the buffer to drain might wait indefinitely (e.g. on termios changes) or that stale data can end up being transmitted in case tx is restarted. Furthermore, the buffer of any port that has been opened would leak on driver unbind. Note that the port lock is held when clearing the buffer pointer due to the ldisc race worked around by commit a5ba1d95e46e ("uart: fix race between uart_put_char() and uart_shutdown()"). Also note that the tty-port shutdown() callback is not called for console ports so it is not strictly necessary to free the buffer page after releasing the lock (cf. d72402145ace ("tty/serial: do not free trasnmit buffer page under port lock")).
- https://git.kernel.org/stable/c/00de977f9e0aa9760d9a79d1e41ff780f74e3424
- https://git.kernel.org/stable/c/011f6c92b5bf6e1fbfdedc8b5232f64c1c493206
- https://git.kernel.org/stable/c/1179b168fa3f3a6aae3bd140000455a0e58457db
- https://git.kernel.org/stable/c/64e491c1634b73d3bddc081d08620bdc92ab2c12
- https://git.kernel.org/stable/c/c5da8aa441053958594f94254592bb41264bdfbf
- https://git.kernel.org/stable/c/e1722acf4f0d4d67b60f57e08ce16f8b66cd4b8f
- https://git.kernel.org/stable/c/e74d9663fd57640fc3394abb5c76fa95b9cc2f2e
- https://git.kernel.org/stable/c/00de977f9e0aa9760d9a79d1e41ff780f74e3424
- https://git.kernel.org/stable/c/011f6c92b5bf6e1fbfdedc8b5232f64c1c493206
- https://git.kernel.org/stable/c/1179b168fa3f3a6aae3bd140000455a0e58457db
- https://git.kernel.org/stable/c/64e491c1634b73d3bddc081d08620bdc92ab2c12
- https://git.kernel.org/stable/c/c5da8aa441053958594f94254592bb41264bdfbf
- https://git.kernel.org/stable/c/e1722acf4f0d4d67b60f57e08ce16f8b66cd4b8f
- https://git.kernel.org/stable/c/e74d9663fd57640fc3394abb5c76fa95b9cc2f2e
Modified: 2025-04-01
CVE-2021-47535
In the Linux kernel, the following vulnerability has been resolved: drm/msm/a6xx: Allocate enough space for GMU registers In commit 142639a52a01 ("drm/msm/a6xx: fix crashstate capture for A650") we changed a6xx_get_gmu_registers() to read 3 sets of registers. Unfortunately, we didn't change the memory allocation for the array. That leads to a KASAN warning (this was on the chromeos-5.4 kernel, which has the problematic commit backported to it): BUG: KASAN: slab-out-of-bounds in _a6xx_get_gmu_registers+0x144/0x430 Write of size 8 at addr ffffff80c89432b0 by task A618-worker/209 CPU: 5 PID: 209 Comm: A618-worker Tainted: G W 5.4.156-lockdep #22 Hardware name: Google Lazor Limozeen without Touchscreen (rev5 - rev8) (DT) Call trace: dump_backtrace+0x0/0x248 show_stack+0x20/0x2c dump_stack+0x128/0x1ec print_address_description+0x88/0x4a0 __kasan_report+0xfc/0x120 kasan_report+0x10/0x18 __asan_report_store8_noabort+0x1c/0x24 _a6xx_get_gmu_registers+0x144/0x430 a6xx_gpu_state_get+0x330/0x25d4 msm_gpu_crashstate_capture+0xa0/0x84c recover_worker+0x328/0x838 kthread_worker_fn+0x32c/0x574 kthread+0x2dc/0x39c ret_from_fork+0x10/0x18 Allocated by task 209: __kasan_kmalloc+0xfc/0x1c4 kasan_kmalloc+0xc/0x14 kmem_cache_alloc_trace+0x1f0/0x2a0 a6xx_gpu_state_get+0x164/0x25d4 msm_gpu_crashstate_capture+0xa0/0x84c recover_worker+0x328/0x838 kthread_worker_fn+0x32c/0x574 kthread+0x2dc/0x39c ret_from_fork+0x10/0x18
- https://git.kernel.org/stable/c/83e54fcf0b14ca2d869dd37abe1bb6542805f538
- https://git.kernel.org/stable/c/b4d25abf9720b69a03465b09d0d62d1998ed6708
- https://git.kernel.org/stable/c/d646856a600e8635ba498f20b194219b158626e8
- https://git.kernel.org/stable/c/83e54fcf0b14ca2d869dd37abe1bb6542805f538
- https://git.kernel.org/stable/c/b4d25abf9720b69a03465b09d0d62d1998ed6708
- https://git.kernel.org/stable/c/d646856a600e8635ba498f20b194219b158626e8
Modified: 2025-09-18
CVE-2021-47536
In the Linux kernel, the following vulnerability has been resolved: net/smc: fix wrong list_del in smc_lgr_cleanup_early smc_lgr_cleanup_early() meant to delete the link group from the link group list, but it deleted the list head by mistake. This may cause memory corruption since we didn't remove the real link group from the list and later memseted the link group structure. We got a list corruption panic when testing: [ 231.277259] list_del corruption. prev->next should be ffff8881398a8000, but was 0000000000000000 [ 231.278222] ------------[ cut here ]------------ [ 231.278726] kernel BUG at lib/list_debug.c:53! [ 231.279326] invalid opcode: 0000 [#1] SMP NOPTI [ 231.279803] CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.10.46+ #435 [ 231.280466] Hardware name: Alibaba Cloud ECS, BIOS 8c24b4c 04/01/2014 [ 231.281248] Workqueue: events smc_link_down_work [ 231.281732] RIP: 0010:__list_del_entry_valid+0x70/0x90 [ 231.282258] Code: 4c 60 82 e8 7d cc 6a 00 0f 0b 48 89 fe 48 c7 c7 88 4c 60 82 e8 6c cc 6a 00 0f 0b 48 89 fe 48 c7 c7 c0 4c 60 82 e8 5b cc 6a 00 <0f> 0b 48 89 fe 48 c7 c7 00 4d 60 82 e8 4a cc 6a 00 0f 0b cc cc cc [ 231.284146] RSP: 0018:ffffc90000033d58 EFLAGS: 00010292 [ 231.284685] RAX: 0000000000000054 RBX: ffff8881398a8000 RCX: 0000000000000000 [ 231.285415] RDX: 0000000000000001 RSI: ffff88813bc18040 RDI: ffff88813bc18040 [ 231.286141] RBP: ffffffff8305ad40 R08: 0000000000000003 R09: 0000000000000001 [ 231.286873] R10: ffffffff82803da0 R11: ffffc90000033b90 R12: 0000000000000001 [ 231.287606] R13: 0000000000000000 R14: ffff8881398a8000 R15: 0000000000000003 [ 231.288337] FS: 0000000000000000(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 [ 231.289160] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 231.289754] CR2: 0000000000e72058 CR3: 000000010fa96006 CR4: 00000000003706f0 [ 231.290485] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 231.291211] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 231.291940] Call Trace: [ 231.292211] smc_lgr_terminate_sched+0x53/0xa0 [ 231.292677] smc_switch_conns+0x75/0x6b0 [ 231.293085] ? update_load_avg+0x1a6/0x590 [ 231.293517] ? ttwu_do_wakeup+0x17/0x150 [ 231.293907] ? update_load_avg+0x1a6/0x590 [ 231.294317] ? newidle_balance+0xca/0x3d0 [ 231.294716] smcr_link_down+0x50/0x1a0 [ 231.295090] ? __wake_up_common_lock+0x77/0x90 [ 231.295534] smc_link_down_work+0x46/0x60 [ 231.295933] process_one_work+0x18b/0x350
- https://git.kernel.org/stable/c/77731fede297a23d26f2d169b4269466b2c82529
- https://git.kernel.org/stable/c/789b6cc2a5f9123b9c549b886fdc47c865cfe0ba
- https://git.kernel.org/stable/c/95518fe354d712dca6f431cf2a11b8f63bc9a66c
- https://git.kernel.org/stable/c/77731fede297a23d26f2d169b4269466b2c82529
- https://git.kernel.org/stable/c/789b6cc2a5f9123b9c549b886fdc47c865cfe0ba
- https://git.kernel.org/stable/c/95518fe354d712dca6f431cf2a11b8f63bc9a66c
Modified: 2025-09-18
CVE-2021-47538
In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix rxrpc_local leak in rxrpc_lookup_peer() Need to call rxrpc_put_local() for peer candidate before kfree() as it holds a ref to rxrpc_local. [DH: v2: Changed to abstract the peer freeing code out into a function]
- https://git.kernel.org/stable/c/3e70e3a72d80b16094faccbe438cd53761c3503a
- https://git.kernel.org/stable/c/60f0b9c42cb80833a03ca57c1c8b078d716e71d1
- https://git.kernel.org/stable/c/913c24af2d13a3fd304462916ee98e298d56bdce
- https://git.kernel.org/stable/c/9469273e616ca8f1b6e3773c5019f21b4c8d828c
- https://git.kernel.org/stable/c/beacff50edbd6c9659a6f15fc7f6126909fade29
- https://git.kernel.org/stable/c/3e70e3a72d80b16094faccbe438cd53761c3503a
- https://git.kernel.org/stable/c/60f0b9c42cb80833a03ca57c1c8b078d716e71d1
- https://git.kernel.org/stable/c/913c24af2d13a3fd304462916ee98e298d56bdce
- https://git.kernel.org/stable/c/9469273e616ca8f1b6e3773c5019f21b4c8d828c
- https://git.kernel.org/stable/c/beacff50edbd6c9659a6f15fc7f6126909fade29
Modified: 2025-09-18
CVE-2021-47539
In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix rxrpc_peer leak in rxrpc_look_up_bundle() Need to call rxrpc_put_peer() for bundle candidate before kfree() as it holds a ref to rxrpc_peer. [DH: v2: Changed to abstract out the bundle freeing code into a function]
- https://git.kernel.org/stable/c/35b40f724c4ef0f683d94dab3af9ab38261d782b
- https://git.kernel.org/stable/c/bc97458620e38961af9505cc060ad4cf5c9e4af7
- https://git.kernel.org/stable/c/ca77fba821351190777b236ce749d7c4d353102e
- https://git.kernel.org/stable/c/35b40f724c4ef0f683d94dab3af9ab38261d782b
- https://git.kernel.org/stable/c/bc97458620e38961af9505cc060ad4cf5c9e4af7
- https://git.kernel.org/stable/c/ca77fba821351190777b236ce749d7c4d353102e
Modified: 2024-11-21
CVE-2021-47540
In the Linux kernel, the following vulnerability has been resolved: mt76: mt7915: fix NULL pointer dereference in mt7915_get_phy_mode Fix the following NULL pointer dereference in mt7915_get_phy_mode routine adding an ibss interface to the mt7915 driver. [ 101.137097] wlan0: Trigger new scan to find an IBSS to join [ 102.827039] wlan0: Creating new IBSS network, BSSID 26:a4:50:1a:6e:69 [ 103.064756] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 103.073670] Mem abort info: [ 103.076520] ESR = 0x96000005 [ 103.079614] EC = 0x25: DABT (current EL), IL = 32 bits [ 103.084934] SET = 0, FnV = 0 [ 103.088042] EA = 0, S1PTW = 0 [ 103.091215] Data abort info: [ 103.094104] ISV = 0, ISS = 0x00000005 [ 103.098041] CM = 0, WnR = 0 [ 103.101044] user pgtable: 4k pages, 39-bit VAs, pgdp=00000000460b1000 [ 103.107565] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 103.116590] Internal error: Oops: 96000005 [#1] SMP [ 103.189066] CPU: 1 PID: 333 Comm: kworker/u4:3 Not tainted 5.10.75 #0 [ 103.195498] Hardware name: MediaTek MT7622 RFB1 board (DT) [ 103.201124] Workqueue: phy0 ieee80211_iface_work [mac80211] [ 103.206695] pstate: 20000005 (nzCv daif -PAN -UAO -TCO BTYPE=--) [ 103.212705] pc : mt7915_get_phy_mode+0x68/0x120 [mt7915e] [ 103.218103] lr : mt7915_mcu_add_bss_info+0x11c/0x760 [mt7915e] [ 103.223927] sp : ffffffc011cdb9e0 [ 103.227235] x29: ffffffc011cdb9e0 x28: ffffff8006563098 [ 103.232545] x27: ffffff8005f4da22 x26: ffffff800685ac40 [ 103.237855] x25: 0000000000000001 x24: 000000000000011f [ 103.243165] x23: ffffff8005f4e260 x22: ffffff8006567918 [ 103.248475] x21: ffffff8005f4df80 x20: ffffff800685ac58 [ 103.253785] x19: ffffff8006744400 x18: 0000000000000000 [ 103.259094] x17: 0000000000000000 x16: 0000000000000001 [ 103.264403] x15: 000899c3a2d9d2e4 x14: 000899bdc3c3a1c8 [ 103.269713] x13: 0000000000000000 x12: 0000000000000000 [ 103.275024] x11: ffffffc010e30c20 x10: 0000000000000000 [ 103.280333] x9 : 0000000000000050 x8 : ffffff8006567d88 [ 103.285642] x7 : ffffff8006563b5c x6 : ffffff8006563b44 [ 103.290952] x5 : 0000000000000002 x4 : 0000000000000001 [ 103.296262] x3 : 0000000000000001 x2 : 0000000000000001 [ 103.301572] x1 : 0000000000000000 x0 : 0000000000000011 [ 103.306882] Call trace: [ 103.309328] mt7915_get_phy_mode+0x68/0x120 [mt7915e] [ 103.314378] mt7915_bss_info_changed+0x198/0x200 [mt7915e] [ 103.319941] ieee80211_bss_info_change_notify+0x128/0x290 [mac80211] [ 103.326360] __ieee80211_sta_join_ibss+0x308/0x6c4 [mac80211] [ 103.332171] ieee80211_sta_create_ibss+0x8c/0x10c [mac80211] [ 103.337895] ieee80211_ibss_work+0x3dc/0x614 [mac80211] [ 103.343185] ieee80211_iface_work+0x388/0x3f0 [mac80211] [ 103.348495] process_one_work+0x288/0x690 [ 103.352499] worker_thread+0x70/0x464 [ 103.356157] kthread+0x144/0x150 [ 103.359380] ret_from_fork+0x10/0x18 [ 103.362952] Code: 394008c3 52800220 394000e4 7100007f (39400023)
- https://git.kernel.org/stable/c/14b03b8cebdf18ff13c39d58501b625411314de2
- https://git.kernel.org/stable/c/6e53d6d26920d5221d3f4d4f5ffdd629ea69aa5c
- https://git.kernel.org/stable/c/932b338f4e5c4cb0c2ed640da3bced1e63620198
- https://git.kernel.org/stable/c/14b03b8cebdf18ff13c39d58501b625411314de2
- https://git.kernel.org/stable/c/6e53d6d26920d5221d3f4d4f5ffdd629ea69aa5c
- https://git.kernel.org/stable/c/932b338f4e5c4cb0c2ed640da3bced1e63620198
Modified: 2024-11-21
CVE-2021-47541
In the Linux kernel, the following vulnerability has been resolved: net/mlx4_en: Fix an use-after-free bug in mlx4_en_try_alloc_resources() In mlx4_en_try_alloc_resources(), mlx4_en_copy_priv() is called and tmp->tx_cq will be freed on the error path of mlx4_en_copy_priv(). After that mlx4_en_alloc_resources() is called and there is a dereference of &tmp->tx_cq[t][i] in mlx4_en_alloc_resources(), which could lead to a use after free problem on failure of mlx4_en_copy_priv(). Fix this bug by adding a check of mlx4_en_copy_priv() This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs. Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug. Builds with CONFIG_MLX4_EN=m show no new warnings, and our static analyzer no longer warns about this code.
- https://git.kernel.org/stable/c/676dc7d9b15bf8733233a2db1ec3f9091ab34275
- https://git.kernel.org/stable/c/75917372eef0dbfb290ae45474314d35f97aea18
- https://git.kernel.org/stable/c/addad7643142f500080417dd7272f49b7a185570
- https://git.kernel.org/stable/c/be12572c5ddc8ad7453bada4eec8fa46967dc757
- https://git.kernel.org/stable/c/e461a9816a1ac5b4aeb61621b817225b61e46a68
- https://git.kernel.org/stable/c/f1d43efa59f1edd3e7eca0e94559b4c6b1cd4e2b
- https://git.kernel.org/stable/c/676dc7d9b15bf8733233a2db1ec3f9091ab34275
- https://git.kernel.org/stable/c/75917372eef0dbfb290ae45474314d35f97aea18
- https://git.kernel.org/stable/c/addad7643142f500080417dd7272f49b7a185570
- https://git.kernel.org/stable/c/be12572c5ddc8ad7453bada4eec8fa46967dc757
- https://git.kernel.org/stable/c/e461a9816a1ac5b4aeb61621b817225b61e46a68
- https://git.kernel.org/stable/c/f1d43efa59f1edd3e7eca0e94559b4c6b1cd4e2b
Modified: 2024-11-21
CVE-2021-47542
In the Linux kernel, the following vulnerability has been resolved: net: qlogic: qlcnic: Fix a NULL pointer dereference in qlcnic_83xx_add_rings() In qlcnic_83xx_add_rings(), the indirect function of ahw->hw_ops->alloc_mbx_args will be called to allocate memory for cmd.req.arg, and there is a dereference of it in qlcnic_83xx_add_rings(), which could lead to a NULL pointer dereference on failure of the indirect function like qlcnic_83xx_alloc_mbx_args(). Fix this bug by adding a check of alloc_mbx_args(), this patch imitates the logic of mbx_cmd()'s failure handling. This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs. Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug. Builds with CONFIG_QLCNIC=m show no new warnings, and our static analyzer no longer warns about this code.
- https://git.kernel.org/stable/c/15fa12c119f869173f9b710cbe6a4a14071d2105
- https://git.kernel.org/stable/c/3a061d54e260b701b538873b43e399d9b8b83e03
- https://git.kernel.org/stable/c/550658a2d61e4eaf522c8ebc7fad76dc376bfb45
- https://git.kernel.org/stable/c/57af54a56024435d83e44c78449513b414eb6edf
- https://git.kernel.org/stable/c/b4f217d6fcc00c3fdc0921a7691f30be7490b073
- https://git.kernel.org/stable/c/bbeb0325a7460ebf1e03f5e0bfc5c652fba9519f
- https://git.kernel.org/stable/c/c5ef33c1489b2cd74368057fa00b5d2183bb5853
- https://git.kernel.org/stable/c/e2dabc4f7e7b60299c20a36d6a7b24ed9bf8e572
- https://git.kernel.org/stable/c/15fa12c119f869173f9b710cbe6a4a14071d2105
- https://git.kernel.org/stable/c/3a061d54e260b701b538873b43e399d9b8b83e03
- https://git.kernel.org/stable/c/550658a2d61e4eaf522c8ebc7fad76dc376bfb45
- https://git.kernel.org/stable/c/57af54a56024435d83e44c78449513b414eb6edf
- https://git.kernel.org/stable/c/b4f217d6fcc00c3fdc0921a7691f30be7490b073
- https://git.kernel.org/stable/c/bbeb0325a7460ebf1e03f5e0bfc5c652fba9519f
- https://git.kernel.org/stable/c/c5ef33c1489b2cd74368057fa00b5d2183bb5853
- https://git.kernel.org/stable/c/e2dabc4f7e7b60299c20a36d6a7b24ed9bf8e572
Modified: 2025-09-18
CVE-2021-47544
In the Linux kernel, the following vulnerability has been resolved: tcp: fix page frag corruption on page fault Steffen reported a TCP stream corruption for HTTP requests served by the apache web-server using a cifs mount-point and memory mapping the relevant file. The root cause is quite similar to the one addressed by commit 20eb4f29b602 ("net: fix sk_page_frag() recursion from memory reclaim"). Here the nested access to the task page frag is caused by a page fault on the (mmapped) user-space memory buffer coming from the cifs file. The page fault handler performs an smb transaction on a different socket, inside the same process context. Since sk->sk_allaction for such socket does not prevent the usage for the task_frag, the nested allocation modify "under the hood" the page frag in use by the outer sendmsg call, corrupting the stream. The overall relevant stack trace looks like the following: httpd 78268 [001] 3461630.850950: probe:tcp_sendmsg_locked: ffffffff91461d91 tcp_sendmsg_locked+0x1 ffffffff91462b57 tcp_sendmsg+0x27 ffffffff9139814e sock_sendmsg+0x3e ffffffffc06dfe1d smb_send_kvec+0x28 [...] ffffffffc06cfaf8 cifs_readpages+0x213 ffffffff90e83c4b read_pages+0x6b ffffffff90e83f31 __do_page_cache_readahead+0x1c1 ffffffff90e79e98 filemap_fault+0x788 ffffffff90eb0458 __do_fault+0x38 ffffffff90eb5280 do_fault+0x1a0 ffffffff90eb7c84 __handle_mm_fault+0x4d4 ffffffff90eb8093 handle_mm_fault+0xc3 ffffffff90c74f6d __do_page_fault+0x1ed ffffffff90c75277 do_page_fault+0x37 ffffffff9160111e page_fault+0x1e ffffffff9109e7b5 copyin+0x25 ffffffff9109eb40 _copy_from_iter_full+0xe0 ffffffff91462370 tcp_sendmsg_locked+0x5e0 ffffffff91462370 tcp_sendmsg_locked+0x5e0 ffffffff91462b57 tcp_sendmsg+0x27 ffffffff9139815c sock_sendmsg+0x4c ffffffff913981f7 sock_write_iter+0x97 ffffffff90f2cc56 do_iter_readv_writev+0x156 ffffffff90f2dff0 do_iter_write+0x80 ffffffff90f2e1c3 vfs_writev+0xa3 ffffffff90f2e27c do_writev+0x5c ffffffff90c042bb do_syscall_64+0x5b ffffffff916000ad entry_SYSCALL_64_after_hwframe+0x65 The cifs filesystem rightfully sets sk_allocations to GFP_NOFS, we can avoid the nesting using the sk page frag for allocation lacking the __GFP_FS flag. Do not define an additional mm-helper for that, as this is strictly tied to the sk page frag usage. v1 -> v2: - use a stricted sk_page_frag() check instead of reordering the code (Eric)
- https://git.kernel.org/stable/c/5a9afcd827cafe14a95c9fcbded2c2d104f18dfc
- https://git.kernel.org/stable/c/c6f340a331fb72e5ac23a083de9c780e132ca3ae
- https://git.kernel.org/stable/c/dacb5d8875cc6cd3a553363b4d6f06760fcbe70c
- https://git.kernel.org/stable/c/5a9afcd827cafe14a95c9fcbded2c2d104f18dfc
- https://git.kernel.org/stable/c/c6f340a331fb72e5ac23a083de9c780e132ca3ae
- https://git.kernel.org/stable/c/dacb5d8875cc6cd3a553363b4d6f06760fcbe70c
Modified: 2024-11-21
CVE-2021-47546
In the Linux kernel, the following vulnerability has been resolved: ipv6: fix memory leak in fib6_rule_suppress The kernel leaks memory when a `fib` rule is present in IPv6 nftables firewall rules and a suppress_prefix rule is present in the IPv6 routing rules (used by certain tools such as wg-quick). In such scenarios, every incoming packet will leak an allocation in `ip6_dst_cache` slab cache. After some hours of `bpftrace`-ing and source code reading, I tracked down the issue to ca7a03c41753 ("ipv6: do not free rt if FIB_LOOKUP_NOREF is set on suppress rule"). The problem with that change is that the generic `args->flags` always have `FIB_LOOKUP_NOREF` set[1][2] but the IPv6-specific flag `RT6_LOOKUP_F_DST_NOREF` might not be, leading to `fib6_rule_suppress` not decreasing the refcount when needed. How to reproduce: - Add the following nftables rule to a prerouting chain: meta nfproto ipv6 fib saddr . mark . iif oif missing drop This can be done with: sudo nft create table inet test sudo nft create chain inet test test_chain '{ type filter hook prerouting priority filter + 10; policy accept; }' sudo nft add rule inet test test_chain meta nfproto ipv6 fib saddr . mark . iif oif missing drop - Run: sudo ip -6 rule add table main suppress_prefixlength 0 - Watch `sudo slabtop -o | grep ip6_dst_cache` to see memory usage increase with every incoming ipv6 packet. This patch exposes the protocol-specific flags to the protocol specific `suppress` function, and check the protocol-specific `flags` argument for RT6_LOOKUP_F_DST_NOREF instead of the generic FIB_LOOKUP_NOREF when decreasing the refcount, like this. [1]: https://github.com/torvalds/linux/blob/ca7a03c4175366a92cee0ccc4fec0038c3266e26/net/ipv6/fib6_rules.c#L71 [2]: https://github.com/torvalds/linux/blob/ca7a03c4175366a92cee0ccc4fec0038c3266e26/net/ipv6/fib6_rules.c#L99
- https://git.kernel.org/stable/c/209d35ee34e25f9668c404350a1c86d914c54ffa
- https://git.kernel.org/stable/c/8ef8a76a340ebdb2c2eea3f6fb0ebbed09a16383
- https://git.kernel.org/stable/c/cdef485217d30382f3bf6448c54b4401648fe3f1
- https://git.kernel.org/stable/c/ee38eb8cf9a7323884c2b8e0adbbeb2192d31e29
- https://git.kernel.org/stable/c/209d35ee34e25f9668c404350a1c86d914c54ffa
- https://git.kernel.org/stable/c/8ef8a76a340ebdb2c2eea3f6fb0ebbed09a16383
- https://git.kernel.org/stable/c/cdef485217d30382f3bf6448c54b4401648fe3f1
- https://git.kernel.org/stable/c/ee38eb8cf9a7323884c2b8e0adbbeb2192d31e29
Modified: 2025-04-01
CVE-2021-47547
In the Linux kernel, the following vulnerability has been resolved: net: tulip: de4x5: fix the problem that the array 'lp->phy[8]' may be out of bound In line 5001, if all id in the array 'lp->phy[8]' is not 0, when the 'for' end, the 'k' is 8. At this time, the array 'lp->phy[8]' may be out of bound.
- https://git.kernel.org/stable/c/12f907cb11576b8cd0b1d95a16d1f10ed5bb7237
- https://git.kernel.org/stable/c/142ead3dc70411bd5977e8c47a6d8bf22287b3f8
- https://git.kernel.org/stable/c/2c1a6a9a011d622a7c61324a97a49801ba425eff
- https://git.kernel.org/stable/c/61217be886b5f7402843677e4be7e7e83de9cb41
- https://git.kernel.org/stable/c/77ff166909458646e66450e42909e0adacc99049
- https://git.kernel.org/stable/c/d3dedaa5a601107cfedda087209772c76e364d58
- https://git.kernel.org/stable/c/ec5bd0aef1cec96830d0c7e06d3597d9e786cc98
- https://git.kernel.org/stable/c/f059fa40f0fcc6bc7a12e0f2a2504e9a4ff74f1f
- https://git.kernel.org/stable/c/12f907cb11576b8cd0b1d95a16d1f10ed5bb7237
- https://git.kernel.org/stable/c/142ead3dc70411bd5977e8c47a6d8bf22287b3f8
- https://git.kernel.org/stable/c/2c1a6a9a011d622a7c61324a97a49801ba425eff
- https://git.kernel.org/stable/c/61217be886b5f7402843677e4be7e7e83de9cb41
- https://git.kernel.org/stable/c/77ff166909458646e66450e42909e0adacc99049
- https://git.kernel.org/stable/c/d3dedaa5a601107cfedda087209772c76e364d58
- https://git.kernel.org/stable/c/ec5bd0aef1cec96830d0c7e06d3597d9e786cc98
- https://git.kernel.org/stable/c/f059fa40f0fcc6bc7a12e0f2a2504e9a4ff74f1f
Modified: 2025-04-01
CVE-2021-47548
In the Linux kernel, the following vulnerability has been resolved: ethernet: hisilicon: hns: hns_dsaf_misc: fix a possible array overflow in hns_dsaf_ge_srst_by_port() The if statement: if (port >= DSAF_GE_NUM) return; limits the value of port less than DSAF_GE_NUM (i.e., 8). However, if the value of port is 6 or 7, an array overflow could occur: port_rst_off = dsaf_dev->mac_cb[port]->port_rst_off; because the length of dsaf_dev->mac_cb is DSAF_MAX_PORT_NUM (i.e., 6). To fix this possible array overflow, we first check port and if it is greater than or equal to DSAF_MAX_PORT_NUM, the function returns.
- https://git.kernel.org/stable/c/22519eff7df2d88adcc2568d86046ce1e2b52803
- https://git.kernel.org/stable/c/948968f8747650447c8f21c9fdba0e1973be040b
- https://git.kernel.org/stable/c/99bb25cb6753beaf2c2bc37927c2ecc0ceff3f6d
- https://git.kernel.org/stable/c/a66998e0fbf213d47d02813b9679426129d0d114
- https://git.kernel.org/stable/c/abbd5faa0748d0aa95d5191d56ff7a17a6275bd1
- https://git.kernel.org/stable/c/dd07f8971b81ad98cc754b179b331b57f35aa1ff
- https://git.kernel.org/stable/c/fc7ffa7f10b9454a86369405d9814bf141b30627
- https://git.kernel.org/stable/c/22519eff7df2d88adcc2568d86046ce1e2b52803
- https://git.kernel.org/stable/c/948968f8747650447c8f21c9fdba0e1973be040b
- https://git.kernel.org/stable/c/99bb25cb6753beaf2c2bc37927c2ecc0ceff3f6d
- https://git.kernel.org/stable/c/a66998e0fbf213d47d02813b9679426129d0d114
- https://git.kernel.org/stable/c/abbd5faa0748d0aa95d5191d56ff7a17a6275bd1
- https://git.kernel.org/stable/c/dd07f8971b81ad98cc754b179b331b57f35aa1ff
- https://git.kernel.org/stable/c/fc7ffa7f10b9454a86369405d9814bf141b30627
Modified: 2025-01-07
CVE-2021-47549
In the Linux kernel, the following vulnerability has been resolved: sata_fsl: fix UAF in sata_fsl_port_stop when rmmod sata_fsl When the `rmmod sata_fsl.ko` command is executed in the PPC64 GNU/Linux, a bug is reported: ================================================================== BUG: Unable to handle kernel data access on read at 0x80000800805b502c Oops: Kernel access of bad area, sig: 11 [#1] NIP [c0000000000388a4] .ioread32+0x4/0x20 LR [80000000000c6034] .sata_fsl_port_stop+0x44/0xe0 [sata_fsl] Call Trace: .free_irq+0x1c/0x4e0 (unreliable) .ata_host_stop+0x74/0xd0 [libata] .release_nodes+0x330/0x3f0 .device_release_driver_internal+0x178/0x2c0 .driver_detach+0x64/0xd0 .bus_remove_driver+0x70/0xf0 .driver_unregister+0x38/0x80 .platform_driver_unregister+0x14/0x30 .fsl_sata_driver_exit+0x18/0xa20 [sata_fsl] .__se_sys_delete_module+0x1ec/0x2d0 .system_call_exception+0xfc/0x1f0 system_call_common+0xf8/0x200 ================================================================== The triggering of the BUG is shown in the following stack: driver_detach device_release_driver_internal __device_release_driver drv->remove(dev) --> platform_drv_remove/platform_remove drv->remove(dev) --> sata_fsl_remove iounmap(host_priv->hcr_base); <---- unmap kfree(host_priv); <---- free devres_release_all release_nodes dr->node.release(dev, dr->data) --> ata_host_stop ap->ops->port_stop(ap) --> sata_fsl_port_stop ioread32(hcr_base + HCONTROL) <---- UAF host->ops->host_stop(host) The iounmap(host_priv->hcr_base) and kfree(host_priv) functions should not be executed in drv->remove. These functions should be executed in host_stop after port_stop. Therefore, we move these functions to the new function sata_fsl_host_stop and bind the new function to host_stop.
- https://git.kernel.org/stable/c/0769449b0a5eabc3545337217ae690e46673e73a
- https://git.kernel.org/stable/c/325ea49fc43cbc03a5e1e37de8f0ca6357ced4b1
- https://git.kernel.org/stable/c/4a46b2f5dce02539e88a300800812bd24a45e097
- https://git.kernel.org/stable/c/6c8ad7e8cf29eb55836e7a0215f967746ab2b504
- https://git.kernel.org/stable/c/77393806c76b6b44f1c44bd957788c8bd9152c45
- https://git.kernel.org/stable/c/91ba94d3f7afca195b224f77a72044fbde1389ce
- https://git.kernel.org/stable/c/adf098e2a8a1e1fc075d6a5ba2edd13cf7189082
- https://git.kernel.org/stable/c/cdcd80292106df5cda325426e96495503e41f947
- https://git.kernel.org/stable/c/0769449b0a5eabc3545337217ae690e46673e73a
- https://git.kernel.org/stable/c/325ea49fc43cbc03a5e1e37de8f0ca6357ced4b1
- https://git.kernel.org/stable/c/4a46b2f5dce02539e88a300800812bd24a45e097
- https://git.kernel.org/stable/c/6c8ad7e8cf29eb55836e7a0215f967746ab2b504
- https://git.kernel.org/stable/c/77393806c76b6b44f1c44bd957788c8bd9152c45
- https://git.kernel.org/stable/c/91ba94d3f7afca195b224f77a72044fbde1389ce
- https://git.kernel.org/stable/c/adf098e2a8a1e1fc075d6a5ba2edd13cf7189082
- https://git.kernel.org/stable/c/cdcd80292106df5cda325426e96495503e41f947
Modified: 2024-11-21
CVE-2021-47550
In the Linux kernel, the following vulnerability has been resolved: drm/amd/amdgpu: fix potential memleak In function amdgpu_get_xgmi_hive, when kobject_init_and_add failed There is a potential memleak if not call kobject_put.
- https://git.kernel.org/stable/c/27dfaedc0d321b4ea4e10c53e4679d6911ab17aa
- https://git.kernel.org/stable/c/75752ada77e0726327adf68018b9f50ae091baeb
- https://git.kernel.org/stable/c/c746945fb6bcbe3863c9ea6369c7ef376e38e5eb
- https://git.kernel.org/stable/c/27dfaedc0d321b4ea4e10c53e4679d6911ab17aa
- https://git.kernel.org/stable/c/75752ada77e0726327adf68018b9f50ae091baeb
- https://git.kernel.org/stable/c/c746945fb6bcbe3863c9ea6369c7ef376e38e5eb
Modified: 2025-04-01
CVE-2021-47551
In the Linux kernel, the following vulnerability has been resolved: drm/amd/amdkfd: Fix kernel panic when reset failed and been triggered again In SRIOV configuration, the reset may failed to bring asic back to normal but stop cpsch already been called, the start_cpsch will not be called since there is no resume in this case. When reset been triggered again, driver should avoid to do uninitialization again.
- https://git.kernel.org/stable/c/06c6f8f86ec243b89e52f0c3dc7062bcb9de74df
- https://git.kernel.org/stable/c/2cf49e00d40d5132e3d067b5aa6d84791929ab15
- https://git.kernel.org/stable/c/74aafe99efb68f15e50be9f7032c2168512f98a8
- https://git.kernel.org/stable/c/06c6f8f86ec243b89e52f0c3dc7062bcb9de74df
- https://git.kernel.org/stable/c/2cf49e00d40d5132e3d067b5aa6d84791929ab15
- https://git.kernel.org/stable/c/74aafe99efb68f15e50be9f7032c2168512f98a8
Modified: 2025-09-18
CVE-2021-47553
In the Linux kernel, the following vulnerability has been resolved: sched/scs: Reset task stack state in bringup_cpu() To hot unplug a CPU, the idle task on that CPU calls a few layers of C code before finally leaving the kernel. When KASAN is in use, poisoned shadow is left around for each of the active stack frames, and when shadow call stacks are in use. When shadow call stacks (SCS) are in use the task's saved SCS SP is left pointing at an arbitrary point within the task's shadow call stack. When a CPU is offlined than onlined back into the kernel, this stale state can adversely affect execution. Stale KASAN shadow can alias new stackframes and result in bogus KASAN warnings. A stale SCS SP is effectively a memory leak, and prevents a portion of the shadow call stack being used. Across a number of hotplug cycles the idle task's entire shadow call stack can become unusable. We previously fixed the KASAN issue in commit: e1b77c92981a5222 ("sched/kasan: remove stale KASAN poison after hotplug") ... by removing any stale KASAN stack poison immediately prior to onlining a CPU. Subsequently in commit: f1a0a376ca0c4ef1 ("sched/core: Initialize the idle task with preemption disabled") ... the refactoring left the KASAN and SCS cleanup in one-time idle thread initialization code rather than something invoked prior to each CPU being onlined, breaking both as above. We fixed SCS (but not KASAN) in commit: 63acd42c0d4942f7 ("sched/scs: Reset the shadow stack when idle_task_exit") ... but as this runs in the context of the idle task being offlined it's potentially fragile. To fix these consistently and more robustly, reset the SCS SP and KASAN shadow of a CPU's idle task immediately before we online that CPU in bringup_cpu(). This ensures the idle task always has a consistent state when it is running, and removes the need to so so when exiting an idle task. Whenever any thread is created, dup_task_struct() will give the task a stack which is free of KASAN shadow, and initialize the task's SCS SP, so there's no need to specially initialize either for idle thread within init_idle(), as this was only necessary to handle hotplug cycles. I've tested this on arm64 with: * gcc 11.1.0, defconfig +KASAN_INLINE, KASAN_STACK * clang 12.0.0, defconfig +KASAN_INLINE, KASAN_STACK, SHADOW_CALL_STACK ... offlining and onlining CPUS with: | while true; do | for C in /sys/devices/system/cpu/cpu*/online; do | echo 0 > $C; | echo 1 > $C; | done | done
- https://git.kernel.org/stable/c/229c555260cb9c1ccdab861e16f0410f1718f302
- https://git.kernel.org/stable/c/dce1ca0525bfdc8a69a9343bc714fbc19a2f04b3
- https://git.kernel.org/stable/c/e6ee7abd6bfe559ad9989004b34c320fd638c526
- https://git.kernel.org/stable/c/229c555260cb9c1ccdab861e16f0410f1718f302
- https://git.kernel.org/stable/c/dce1ca0525bfdc8a69a9343bc714fbc19a2f04b3
- https://git.kernel.org/stable/c/e6ee7abd6bfe559ad9989004b34c320fd638c526
Modified: 2025-09-18
CVE-2021-47555
In the Linux kernel, the following vulnerability has been resolved: net: vlan: fix underflow for the real_dev refcnt Inject error before dev_hold(real_dev) in register_vlan_dev(), and execute the following testcase: ip link add dev dummy1 type dummy ip link add name dummy1.100 link dummy1 type vlan id 100 ip link del dev dummy1 When the dummy netdevice is removed, we will get a WARNING as following: ======================================================================= refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 2 PID: 0 at lib/refcount.c:31 refcount_warn_saturate+0xbf/0x1e0 and an endless loop of: ======================================================================= unregister_netdevice: waiting for dummy1 to become free. Usage count = -1073741824 That is because dev_put(real_dev) in vlan_dev_free() be called without dev_hold(real_dev) in register_vlan_dev(). It makes the refcnt of real_dev underflow. Move the dev_hold(real_dev) to vlan_dev_init() which is the call-back of ndo_init(). That makes dev_hold() and dev_put() for vlan's real_dev symmetrical.
- https://git.kernel.org/stable/c/01d9cc2dea3fde3bad6d27f464eff463496e2b00
- https://git.kernel.org/stable/c/5e44178864b38dd70b877985abd7d86fdb95f27d
- https://git.kernel.org/stable/c/6e800ee43218a56acc93676bbb3d93b74779e555
- https://git.kernel.org/stable/c/f7fc72a508cf115c273a7a29350069def1041890
- https://git.kernel.org/stable/c/01d9cc2dea3fde3bad6d27f464eff463496e2b00
- https://git.kernel.org/stable/c/5e44178864b38dd70b877985abd7d86fdb95f27d
- https://git.kernel.org/stable/c/6e800ee43218a56acc93676bbb3d93b74779e555
- https://git.kernel.org/stable/c/f7fc72a508cf115c273a7a29350069def1041890
Modified: 2025-01-06
CVE-2021-47557
In the Linux kernel, the following vulnerability has been resolved:
net/sched: sch_ets: don't peek at classes beyond 'nbands'
when the number of DRR classes decreases, the round-robin active list can
contain elements that have already been freed in ets_qdisc_change(). As a
consequence, it's possible to see a NULL dereference crash, caused by the
attempt to call cl->qdisc->ops->peek(cl->qdisc) when cl->qdisc is NULL:
BUG: kernel NULL pointer dereference, address: 0000000000000018
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 1 PID: 910 Comm: mausezahn Not tainted 5.16.0-rc1+ #475
Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014
RIP: 0010:ets_qdisc_dequeue+0x129/0x2c0 [sch_ets]
Code: c5 01 41 39 ad e4 02 00 00 0f 87 18 ff ff ff 49 8b 85 c0 02 00 00 49 39 c4 0f 84 ba 00 00 00 49 8b ad c0 02 00 00 48 8b 7d 10 <48> 8b 47 18 48 8b 40 38 0f ae e8 ff d0 48 89 c3 48 85 c0 0f 84 9d
RSP: 0000:ffffbb36c0b5fdd8 EFLAGS: 00010287
RAX: ffff956678efed30 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000002 RSI: ffffffff9b938dc9 RDI: 0000000000000000
RBP: ffff956678efed30 R08: e2f3207fe360129c R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000001 R12: ffff956678efeac0
R13: ffff956678efe800 R14: ffff956611545000 R15: ffff95667ac8f100
FS: 00007f2aa9120740(0000) GS:ffff95667b800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000018 CR3: 000000011070c000 CR4: 0000000000350ee0
Call Trace:
- https://git.kernel.org/stable/c/ae2659d2c670252759ee9c823c4e039c0e05a6f2
- https://git.kernel.org/stable/c/de6d25924c2a8c2988c6a385990cafbe742061bf
- https://git.kernel.org/stable/c/e25bdbc7e951ae5728fee1f4c09485df113d013c
- https://git.kernel.org/stable/c/ae2659d2c670252759ee9c823c4e039c0e05a6f2
- https://git.kernel.org/stable/c/de6d25924c2a8c2988c6a385990cafbe742061bf
- https://git.kernel.org/stable/c/e25bdbc7e951ae5728fee1f4c09485df113d013c
Modified: 2024-11-21
CVE-2021-47559
In the Linux kernel, the following vulnerability has been resolved: net/smc: Fix NULL pointer dereferencing in smc_vlan_by_tcpsk() Coverity reports a possible NULL dereferencing problem: in smc_vlan_by_tcpsk(): 6. returned_null: netdev_lower_get_next returns NULL (checked 29 out of 30 times). 7. var_assigned: Assigning: ndev = NULL return value from netdev_lower_get_next. 1623 ndev = (struct net_device *)netdev_lower_get_next(ndev, &lower); CID 1468509 (#1 of 1): Dereference null return value (NULL_RETURNS) 8. dereference: Dereferencing a pointer that might be NULL ndev when calling is_vlan_dev. 1624 if (is_vlan_dev(ndev)) { Remove the manual implementation and use netdev_walk_all_lower_dev() to iterate over the lower devices. While on it remove an obsolete function parameter comment.
- https://git.kernel.org/stable/c/587acad41f1bc48e16f42bb2aca63bf323380be8
- https://git.kernel.org/stable/c/bb851d0fb02547d03cd40106b5f2391c4fed6ed1
- https://git.kernel.org/stable/c/c94cbd262b6aa3b54d73a1ed1f9c0d19df57f4ff
- https://git.kernel.org/stable/c/587acad41f1bc48e16f42bb2aca63bf323380be8
- https://git.kernel.org/stable/c/bb851d0fb02547d03cd40106b5f2391c4fed6ed1
- https://git.kernel.org/stable/c/c94cbd262b6aa3b54d73a1ed1f9c0d19df57f4ff
Modified: 2025-01-06
CVE-2021-47560
In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum: Protect driver from buggy firmware When processing port up/down events generated by the device's firmware, the driver protects itself from events reported for non-existent local ports, but not the CPU port (local port 0), which exists, but lacks a netdev. This can result in a NULL pointer dereference when calling netif_carrier_{on,off}(). Fix this by bailing early when processing an event reported for the CPU port. Problem was only observed when running on top of a buggy emulator.
- https://git.kernel.org/stable/c/63b08b1f6834bbb0b4f7783bf63b80c8c8e9a047
- https://git.kernel.org/stable/c/90d0736876c50ecde1a3275636a06b9ddb1cace9
- https://git.kernel.org/stable/c/da4d70199e5d82da664a80077508d6c18f5e76df
- https://git.kernel.org/stable/c/63b08b1f6834bbb0b4f7783bf63b80c8c8e9a047
- https://git.kernel.org/stable/c/90d0736876c50ecde1a3275636a06b9ddb1cace9
- https://git.kernel.org/stable/c/da4d70199e5d82da664a80077508d6c18f5e76df
Modified: 2025-01-06
CVE-2021-47562
In the Linux kernel, the following vulnerability has been resolved: ice: fix vsi->txq_map sizing The approach of having XDP queue per CPU regardless of user's setting exposed a hidden bug that could occur in case when Rx queue count differ from Tx queue count. Currently vsi->txq_map's size is equal to the doubled vsi->alloc_txq, which is not correct due to the fact that XDP rings were previously based on the Rx queue count. Below splat can be seen when ethtool -L is used and XDP rings are configured: [ 682.875339] BUG: kernel NULL pointer dereference, address: 000000000000000f [ 682.883403] #PF: supervisor read access in kernel mode [ 682.889345] #PF: error_code(0x0000) - not-present page [ 682.895289] PGD 0 P4D 0 [ 682.898218] Oops: 0000 [#1] PREEMPT SMP PTI [ 682.903055] CPU: 42 PID: 2878 Comm: ethtool Tainted: G OE 5.15.0-rc5+ #1 [ 682.912214] Hardware name: Intel Corp. GRANTLEY/GRANTLEY, BIOS GRRFCRB1.86B.0276.D07.1605190235 05/19/2016 [ 682.923380] RIP: 0010:devres_remove+0x44/0x130 [ 682.928527] Code: 49 89 f4 55 48 89 fd 4c 89 ff 53 48 83 ec 10 e8 92 b9 49 00 48 8b 9d a8 02 00 00 48 8d 8d a0 02 00 00 49 89 c2 48 39 cb 74 0f <4c> 3b 63 10 74 25 48 8b 5b 08 48 39 cb 75 f1 4c 89 ff 4c 89 d6 e8 [ 682.950237] RSP: 0018:ffffc90006a679f0 EFLAGS: 00010002 [ 682.956285] RAX: 0000000000000286 RBX: ffffffffffffffff RCX: ffff88908343a370 [ 682.964538] RDX: 0000000000000001 RSI: ffffffff81690d60 RDI: 0000000000000000 [ 682.972789] RBP: ffff88908343a0d0 R08: 0000000000000000 R09: 0000000000000000 [ 682.981040] R10: 0000000000000286 R11: 3fffffffffffffff R12: ffffffff81690d60 [ 682.989282] R13: ffffffff81690a00 R14: ffff8890819807a8 R15: ffff88908343a36c [ 682.997535] FS: 00007f08c7bfa740(0000) GS:ffff88a03fd00000(0000) knlGS:0000000000000000 [ 683.006910] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 683.013557] CR2: 000000000000000f CR3: 0000001080a66003 CR4: 00000000003706e0 [ 683.021819] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 683.030075] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 683.038336] Call Trace: [ 683.041167] devm_kfree+0x33/0x50 [ 683.045004] ice_vsi_free_arrays+0x5e/0xc0 [ice] [ 683.050380] ice_vsi_rebuild+0x4c8/0x750 [ice] [ 683.055543] ice_vsi_recfg_qs+0x9a/0x110 [ice] [ 683.060697] ice_set_channels+0x14f/0x290 [ice] [ 683.065962] ethnl_set_channels+0x333/0x3f0 [ 683.070807] genl_family_rcv_msg_doit+0xea/0x150 [ 683.076152] genl_rcv_msg+0xde/0x1d0 [ 683.080289] ? channels_prepare_data+0x60/0x60 [ 683.085432] ? genl_get_cmd+0xd0/0xd0 [ 683.089667] netlink_rcv_skb+0x50/0xf0 [ 683.094006] genl_rcv+0x24/0x40 [ 683.097638] netlink_unicast+0x239/0x340 [ 683.102177] netlink_sendmsg+0x22e/0x470 [ 683.106717] sock_sendmsg+0x5e/0x60 [ 683.110756] __sys_sendto+0xee/0x150 [ 683.114894] ? handle_mm_fault+0xd0/0x2a0 [ 683.119535] ? do_user_addr_fault+0x1f3/0x690 [ 683.134173] __x64_sys_sendto+0x25/0x30 [ 683.148231] do_syscall_64+0x3b/0xc0 [ 683.161992] entry_SYSCALL_64_after_hwframe+0x44/0xae Fix this by taking into account the value that num_possible_cpus() yields in addition to vsi->alloc_txq instead of doubling the latter.
- https://git.kernel.org/stable/c/1eb5395add786613c7c5579d3947aa0b8f0ec241
- https://git.kernel.org/stable/c/792b2086584f25d84081a526beee80d103c2a913
- https://git.kernel.org/stable/c/992ba40a67638dfe2772b84dfc8168dc328d5c4c
- https://git.kernel.org/stable/c/1eb5395add786613c7c5579d3947aa0b8f0ec241
- https://git.kernel.org/stable/c/792b2086584f25d84081a526beee80d103c2a913
- https://git.kernel.org/stable/c/992ba40a67638dfe2772b84dfc8168dc328d5c4c
Modified: 2025-04-01
CVE-2021-47563
In the Linux kernel, the following vulnerability has been resolved: ice: avoid bpf_prog refcount underflow Ice driver has the routines for managing XDP resources that are shared between ndo_bpf op and VSI rebuild flow. The latter takes place for example when user changes queue count on an interface via ethtool's set_channels(). There is an issue around the bpf_prog refcounting when VSI is being rebuilt - since ice_prepare_xdp_rings() is called with vsi->xdp_prog as an argument that is used later on by ice_vsi_assign_bpf_prog(), same bpf_prog pointers are swapped with each other. Then it is also interpreted as an 'old_prog' which in turn causes us to call bpf_prog_put on it that will decrement its refcount. Below splat can be interpreted in a way that due to zero refcount of a bpf_prog it is wiped out from the system while kernel still tries to refer to it: [ 481.069429] BUG: unable to handle page fault for address: ffffc9000640f038 [ 481.077390] #PF: supervisor read access in kernel mode [ 481.083335] #PF: error_code(0x0000) - not-present page [ 481.089276] PGD 100000067 P4D 100000067 PUD 1001cb067 PMD 106d2b067 PTE 0 [ 481.097141] Oops: 0000 [#1] PREEMPT SMP PTI [ 481.101980] CPU: 12 PID: 3339 Comm: sudo Tainted: G OE 5.15.0-rc5+ #1 [ 481.110840] Hardware name: Intel Corp. GRANTLEY/GRANTLEY, BIOS GRRFCRB1.86B.0276.D07.1605190235 05/19/2016 [ 481.122021] RIP: 0010:dev_xdp_prog_id+0x25/0x40 [ 481.127265] Code: 80 00 00 00 00 0f 1f 44 00 00 89 f6 48 c1 e6 04 48 01 fe 48 8b 86 98 08 00 00 48 85 c0 74 13 48 8b 50 18 31 c0 48 85 d2 74 07 <48> 8b 42 38 8b 40 20 c3 48 8b 96 90 08 00 00 eb e8 66 2e 0f 1f 84 [ 481.148991] RSP: 0018:ffffc90007b63868 EFLAGS: 00010286 [ 481.155034] RAX: 0000000000000000 RBX: ffff889080824000 RCX: 0000000000000000 [ 481.163278] RDX: ffffc9000640f000 RSI: ffff889080824010 RDI: ffff889080824000 [ 481.171527] RBP: ffff888107af7d00 R08: 0000000000000000 R09: ffff88810db5f6e0 [ 481.179776] R10: 0000000000000000 R11: ffff8890885b9988 R12: ffff88810db5f4bc [ 481.188026] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 481.196276] FS: 00007f5466d5bec0(0000) GS:ffff88903fb00000(0000) knlGS:0000000000000000 [ 481.205633] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 481.212279] CR2: ffffc9000640f038 CR3: 000000014429c006 CR4: 00000000003706e0 [ 481.220530] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 481.228771] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 481.237029] Call Trace: [ 481.239856] rtnl_fill_ifinfo+0x768/0x12e0 [ 481.244602] rtnl_dump_ifinfo+0x525/0x650 [ 481.249246] ? __alloc_skb+0xa5/0x280 [ 481.253484] netlink_dump+0x168/0x3c0 [ 481.257725] netlink_recvmsg+0x21e/0x3e0 [ 481.262263] ____sys_recvmsg+0x87/0x170 [ 481.266707] ? __might_fault+0x20/0x30 [ 481.271046] ? _copy_from_user+0x66/0xa0 [ 481.275591] ? iovec_from_user+0xf6/0x1c0 [ 481.280226] ___sys_recvmsg+0x82/0x100 [ 481.284566] ? sock_sendmsg+0x5e/0x60 [ 481.288791] ? __sys_sendto+0xee/0x150 [ 481.293129] __sys_recvmsg+0x56/0xa0 [ 481.297267] do_syscall_64+0x3b/0xc0 [ 481.301395] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 481.307238] RIP: 0033:0x7f5466f39617 [ 481.311373] Code: 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb bd 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2f 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10 [ 481.342944] RSP: 002b:00007ffedc7f4308 EFLAGS: 00000246 ORIG_RAX: 000000000000002f [ 481.361783] RAX: ffffffffffffffda RBX: 00007ffedc7f5460 RCX: 00007f5466f39617 [ 481.380278] RDX: 0000000000000000 RSI: 00007ffedc7f5360 RDI: 0000000000000003 [ 481.398500] RBP: 00007ffedc7f53f0 R08: 0000000000000000 R09: 000055d556f04d50 [ 481.416463] R10: 0000000000000077 R11: 0000000000000246 R12: 00007ffedc7f5360 [ 481.434131] R13: 00007ffedc7f5350 R14: 00007ffedc7f5344 R15: 0000000000000e98 [ 481.451520] Modules linked in: ice ---truncated---
- https://git.kernel.org/stable/c/1f10b09ccc832698ef4624a6ab9a213b6ccbda76
- https://git.kernel.org/stable/c/e65a8707b4cd756d26d246bb2b9fab06eebafac1
- https://git.kernel.org/stable/c/f65ee535df775a13a1046c0a0b2d72db342f8a5b
- https://git.kernel.org/stable/c/1f10b09ccc832698ef4624a6ab9a213b6ccbda76
- https://git.kernel.org/stable/c/e65a8707b4cd756d26d246bb2b9fab06eebafac1
- https://git.kernel.org/stable/c/f65ee535df775a13a1046c0a0b2d72db342f8a5b
Modified: 2025-01-06
CVE-2021-47564
In the Linux kernel, the following vulnerability has been resolved: net: marvell: prestera: fix double free issue on err path fix error path handling in prestera_bridge_port_join() that cases prestera driver to crash (see below). Trace: Internal error: Oops: 96000044 [#1] SMP Modules linked in: prestera_pci prestera uio_pdrv_genirq CPU: 1 PID: 881 Comm: ip Not tainted 5.15.0 #1 pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : prestera_bridge_destroy+0x2c/0xb0 [prestera] lr : prestera_bridge_port_join+0x2cc/0x350 [prestera] sp : ffff800011a1b0f0 ... x2 : ffff000109ca6c80 x1 : dead000000000100 x0 : dead000000000122 Call trace: prestera_bridge_destroy+0x2c/0xb0 [prestera] prestera_bridge_port_join+0x2cc/0x350 [prestera] prestera_netdev_port_event.constprop.0+0x3c4/0x450 [prestera] prestera_netdev_event_handler+0xf4/0x110 [prestera] raw_notifier_call_chain+0x54/0x80 call_netdevice_notifiers_info+0x54/0xa0 __netdev_upper_dev_link+0x19c/0x380
- https://git.kernel.org/stable/c/03e5203d2161a00afe4d97d206d2293e40b2f253
- https://git.kernel.org/stable/c/5dca8eff4627315df98feec09fff9dfe3356325e
- https://git.kernel.org/stable/c/e8d032507cb7912baf1d3e0af54516f823befefd
- https://git.kernel.org/stable/c/03e5203d2161a00afe4d97d206d2293e40b2f253
- https://git.kernel.org/stable/c/5dca8eff4627315df98feec09fff9dfe3356325e
- https://git.kernel.org/stable/c/e8d032507cb7912baf1d3e0af54516f823befefd
Modified: 2025-09-18
CVE-2021-47565
In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Fix kernel panic during drive powercycle test While looping over shost's sdev list it is possible that one of the drives is getting removed and its sas_target object is freed but its sdev object remains intact. Consequently, a kernel panic can occur while the driver is trying to access the sas_address field of sas_target object without also checking the sas_target object for NULL.
- https://git.kernel.org/stable/c/0d4b29eaadc1f59cec0c7e85eae77d08fcca9824
- https://git.kernel.org/stable/c/0ee4ba13e09c9d9c1cb6abb59da8295d9952328b
- https://git.kernel.org/stable/c/2bf9c5a5039c8f4b037236aed505e6a25c1d5f7b
- https://git.kernel.org/stable/c/58ef2c7a6de13721865d84b80eecf56d6cba0937
- https://git.kernel.org/stable/c/5d4d50b1f159a5ebab7617f47121b4370aa58afe
- https://git.kernel.org/stable/c/7e324f734a914957b8cc3ff4b4c9f0409558adb5
- https://git.kernel.org/stable/c/8485649a7655e791a6e4e9f15b4d30fdae937184
- https://git.kernel.org/stable/c/dd035ca0e7a142870a970d46b1d19276cfe2bc8c
- https://git.kernel.org/stable/c/0d4b29eaadc1f59cec0c7e85eae77d08fcca9824
- https://git.kernel.org/stable/c/0ee4ba13e09c9d9c1cb6abb59da8295d9952328b
- https://git.kernel.org/stable/c/2bf9c5a5039c8f4b037236aed505e6a25c1d5f7b
- https://git.kernel.org/stable/c/58ef2c7a6de13721865d84b80eecf56d6cba0937
- https://git.kernel.org/stable/c/5d4d50b1f159a5ebab7617f47121b4370aa58afe
- https://git.kernel.org/stable/c/7e324f734a914957b8cc3ff4b4c9f0409558adb5
- https://git.kernel.org/stable/c/8485649a7655e791a6e4e9f15b4d30fdae937184
- https://git.kernel.org/stable/c/dd035ca0e7a142870a970d46b1d19276cfe2bc8c
Modified: 2025-09-18
CVE-2021-47566
In the Linux kernel, the following vulnerability has been resolved: proc/vmcore: fix clearing user buffer by properly using clear_user() To clear a user buffer we cannot simply use memset, we have to use clear_user(). With a virtio-mem device that registers a vmcore_cb and has some logically unplugged memory inside an added Linux memory block, I can easily trigger a BUG by copying the vmcore via "cp": systemd[1]: Starting Kdump Vmcore Save Service... kdump[420]: Kdump is using the default log level(3). kdump[453]: saving to /sysroot/var/crash/127.0.0.1-2021-11-11-14:59:22/ kdump[458]: saving vmcore-dmesg.txt to /sysroot/var/crash/127.0.0.1-2021-11-11-14:59:22/ kdump[465]: saving vmcore-dmesg.txt complete kdump[467]: saving vmcore BUG: unable to handle page fault for address: 00007f2374e01000 #PF: supervisor write access in kernel mode #PF: error_code(0x0003) - permissions violation PGD 7a523067 P4D 7a523067 PUD 7a528067 PMD 7a525067 PTE 800000007048f867 Oops: 0003 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 468 Comm: cp Not tainted 5.15.0+ #6 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.14.0-27-g64f37cc530f1-prebuilt.qemu.org 04/01/2014 RIP: 0010:read_from_oldmem.part.0.cold+0x1d/0x86 Code: ff ff ff e8 05 ff fe ff e9 b9 e9 7f ff 48 89 de 48 c7 c7 38 3b 60 82 e8 f1 fe fe ff 83 fd 08 72 3c 49 8d 7d 08 4c 89 e9 89 e8 <49> c7 45 00 00 00 00 00 49 c7 44 05 f8 00 00 00 00 48 83 e7 f81 RSP: 0018:ffffc9000073be08 EFLAGS: 00010212 RAX: 0000000000001000 RBX: 00000000002fd000 RCX: 00007f2374e01000 RDX: 0000000000000001 RSI: 00000000ffffdfff RDI: 00007f2374e01008 RBP: 0000000000001000 R08: 0000000000000000 R09: ffffc9000073bc50 R10: ffffc9000073bc48 R11: ffffffff829461a8 R12: 000000000000f000 R13: 00007f2374e01000 R14: 0000000000000000 R15: ffff88807bd421e8 FS: 00007f2374e12140(0000) GS:ffff88807f000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2374e01000 CR3: 000000007a4aa000 CR4: 0000000000350eb0 Call Trace: read_vmcore+0x236/0x2c0 proc_reg_read+0x55/0xa0 vfs_read+0x95/0x190 ksys_read+0x4f/0xc0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae Some x86-64 CPUs have a CPU feature called "Supervisor Mode Access Prevention (SMAP)", which is used to detect wrong access from the kernel to user buffers like this: SMAP triggers a permissions violation on wrong access. In the x86-64 variant of clear_user(), SMAP is properly handled via clac()+stac(). To fix, properly use clear_user() when we're dealing with a user buffer.
- https://git.kernel.org/stable/c/33a7d698f30fa0b99d50569e9909d3baa65d8f6a
- https://git.kernel.org/stable/c/7b3a34f08d11e7f05cd00b8e09adaa15192f0ad1
- https://git.kernel.org/stable/c/99d348b82bcb36171f24411d3f1a15706a2a937a
- https://git.kernel.org/stable/c/9ef384ed300d1bcfb23d0ab0b487d544444d4b52
- https://git.kernel.org/stable/c/a8a917058faf4abaec9fb614bb6d5f8fe3529ec6
- https://git.kernel.org/stable/c/a9e164bd160be8cbee1df70acb379129e3cd2e7c
- https://git.kernel.org/stable/c/c1e63117711977cc4295b2ce73de29dd17066c82
- https://git.kernel.org/stable/c/fd7974c547abfb03072a4ee706d3a6f182266f89
- https://git.kernel.org/stable/c/33a7d698f30fa0b99d50569e9909d3baa65d8f6a
- https://git.kernel.org/stable/c/7b3a34f08d11e7f05cd00b8e09adaa15192f0ad1
- https://git.kernel.org/stable/c/99d348b82bcb36171f24411d3f1a15706a2a937a
- https://git.kernel.org/stable/c/9ef384ed300d1bcfb23d0ab0b487d544444d4b52
- https://git.kernel.org/stable/c/a8a917058faf4abaec9fb614bb6d5f8fe3529ec6
- https://git.kernel.org/stable/c/a9e164bd160be8cbee1df70acb379129e3cd2e7c
- https://git.kernel.org/stable/c/c1e63117711977cc4295b2ce73de29dd17066c82
- https://git.kernel.org/stable/c/fd7974c547abfb03072a4ee706d3a6f182266f89
Modified: 2025-09-18
CVE-2021-47567
In the Linux kernel, the following vulnerability has been resolved: powerpc/32: Fix hardlockup on vmap stack overflow Since the commit c118c7303ad5 ("powerpc/32: Fix vmap stack - Do not activate MMU before reading task struct") a vmap stack overflow results in a hard lockup. This is because emergency_ctx is still addressed with its virtual address allthough data MMU is not active anymore at that time. Fix it by using a physical address instead.
- https://git.kernel.org/stable/c/5bb60ea611db1e04814426ed4bd1c95d1487678e
- https://git.kernel.org/stable/c/c4e3ff8b8b1d54f0c755670174c453b06e17114b
- https://git.kernel.org/stable/c/dfe906da9a1abebdebe8b15bb3e66a2578f6c4c7
- https://git.kernel.org/stable/c/5bb60ea611db1e04814426ed4bd1c95d1487678e
- https://git.kernel.org/stable/c/c4e3ff8b8b1d54f0c755670174c453b06e17114b
- https://git.kernel.org/stable/c/dfe906da9a1abebdebe8b15bb3e66a2578f6c4c7
Modified: 2024-11-21
CVE-2021-47571
In the Linux kernel, the following vulnerability has been resolved: staging: rtl8192e: Fix use after free in _rtl92e_pci_disconnect() The free_rtllib() function frees the "dev" pointer so there is use after free on the next line. Re-arrange things to avoid that.
- https://git.kernel.org/stable/c/2e1ec01af2c7139c6a600bbfaea1a018b35094b6
- https://git.kernel.org/stable/c/8d0163cec7de995f9eb9c3128c83fb84f0cb1c64
- https://git.kernel.org/stable/c/9186680382934b0e7529d3d70dcc0a21d087683b
- https://git.kernel.org/stable/c/b535917c51acc97fb0761b1edec85f1f3d02bda4
- https://git.kernel.org/stable/c/bca19bb2dc2d89ce60c4a4a6e59609d4cf2e13ef
- https://git.kernel.org/stable/c/c0ef0e75a858cbd8618b473f22fbca36106dcf82
- https://git.kernel.org/stable/c/d43aecb694b10db9a4228ce2d38b5ae8de374443
- https://git.kernel.org/stable/c/e27ee2f607fe6a9b923ef1fc65461c0613c97594
- https://git.kernel.org/stable/c/2e1ec01af2c7139c6a600bbfaea1a018b35094b6
- https://git.kernel.org/stable/c/8d0163cec7de995f9eb9c3128c83fb84f0cb1c64
- https://git.kernel.org/stable/c/9186680382934b0e7529d3d70dcc0a21d087683b
- https://git.kernel.org/stable/c/b535917c51acc97fb0761b1edec85f1f3d02bda4
- https://git.kernel.org/stable/c/bca19bb2dc2d89ce60c4a4a6e59609d4cf2e13ef
- https://git.kernel.org/stable/c/c0ef0e75a858cbd8618b473f22fbca36106dcf82
- https://git.kernel.org/stable/c/d43aecb694b10db9a4228ce2d38b5ae8de374443
- https://git.kernel.org/stable/c/e27ee2f607fe6a9b923ef1fc65461c0613c97594
Modified: 2024-11-21
CVE-2021-47572
In the Linux kernel, the following vulnerability has been resolved:
net: nexthop: fix null pointer dereference when IPv6 is not enabled
When we try to add an IPv6 nexthop and IPv6 is not enabled
(!CONFIG_IPV6) we'll hit a NULL pointer dereference[1] in the error path
of nh_create_ipv6() due to calling ipv6_stub->fib6_nh_release. The bug
has been present since the beginning of IPv6 nexthop gateway support.
Commit 1aefd3de7bc6 ("ipv6: Add fib6_nh_init and release to stubs") tells
us that only fib6_nh_init has a dummy stub because fib6_nh_release should
not be called if fib6_nh_init returns an error, but the commit below added
a call to ipv6_stub->fib6_nh_release in its error path. To fix it return
the dummy stub's -EAFNOSUPPORT error directly without calling
ipv6_stub->fib6_nh_release in nh_create_ipv6()'s error path.
[1]
Output is a bit truncated, but it clearly shows the error.
BUG: kernel NULL pointer dereference, address: 000000000000000000
#PF: supervisor instruction fetch in kernel modede
#PF: error_code(0x0010) - not-present pagege
PGD 0 P4D 0
Oops: 0010 [#1] PREEMPT SMP NOPTI
CPU: 4 PID: 638 Comm: ip Kdump: loaded Not tainted 5.16.0-rc1+ #446
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-4.fc34 04/01/2014
RIP: 0010:0x0
Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6.
RSP: 0018:ffff888109f5b8f0 EFLAGS: 00010286^Ac
RAX: 0000000000000000 RBX: ffff888109f5ba28 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8881008a2860
RBP: ffff888109f5b9d8 R08: 0000000000000000 R09: 0000000000000000
R10: ffff888109f5b978 R11: ffff888109f5b948 R12: 00000000ffffff9f
R13: ffff8881008a2a80 R14: ffff8881008a2860 R15: ffff8881008a2840
FS: 00007f98de70f100(0000) GS:ffff88822bf00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffffffffd6 CR3: 0000000100efc000 CR4: 00000000000006e0
Call Trace:
- https://git.kernel.org/stable/c/1c743127cc54b112b155f434756bd4b5fa565a99
- https://git.kernel.org/stable/c/39509d76a9a3d02f379d52cb4b1449469c56c0e0
- https://git.kernel.org/stable/c/7b6f44856da5ba0b1aa61403eb9fddd272156503
- https://git.kernel.org/stable/c/b70ff391deeec35cdd8a05f5f63f5fe28bc4f225
- https://git.kernel.org/stable/c/1c743127cc54b112b155f434756bd4b5fa565a99
- https://git.kernel.org/stable/c/39509d76a9a3d02f379d52cb4b1449469c56c0e0
- https://git.kernel.org/stable/c/7b6f44856da5ba0b1aa61403eb9fddd272156503
- https://git.kernel.org/stable/c/b70ff391deeec35cdd8a05f5f63f5fe28bc4f225
Modified: 2024-09-03
CVE-2022-48944
In the Linux kernel, the following vulnerability has been resolved: sched: Fix yet more sched_fork() races Where commit 4ef0c5c6b5ba ("kernel/sched: Fix sched_fork() access an invalid sched_task_group") fixed a fork race vs cgroup, it opened up a race vs syscalls by not placing the task on the runqueue before it gets exposed through the pidhash. Commit 13765de8148f ("sched/fair: Fix fault in reweight_entity") is trying to fix a single instance of this, instead fix the whole class of issues, effectively reverting this commit.
