CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2022-48756 – drm/msm/dsi: invalid parameter check in msm_dsi_phy_enable
https://notcve.org/view.php?id=CVE-2022-48756
In the Linux kernel, the following vulnerability has been resolved: drm/msm/dsi: invalid parameter check in msm_dsi_phy_enable The function performs a check on the "phy" input parameter, however, it is used before the check. Initialize the "dev" variable after the sanity check to avoid a possible NULL pointer dereference. Addresses-Coverity-ID: 1493860 ("Null pointer dereference") • https://git.kernel.org/stable/c/5c8290284402bf7d2c12269402b3177b899c78b7 https://git.kernel.org/stable/c/6d9f8ba28f3747ca0f910a363e46f1114856dbbe https://git.kernel.org/stable/c/ca63eeb70fcb53c42e1fe54e1735a54d8e7759fd https://git.kernel.org/stable/c/581317b1f001b7509041544d7019b75571daa100 https://git.kernel.org/stable/c/79c0b5287ded74f4eacde4dfd8aa0a76cbd853b5 https://git.kernel.org/stable/c/56480fb10b976581a363fd168dc2e4fbee87a1a7 https://git.kernel.org/stable/c/2b7e7df1eacd280e561ede3e977853606871c951 https://git.kernel.org/stable/c/5e761a2287234bc402ba7ef07129f5103 •
CVSS: 7.5EPSS: 0%CPEs: 5EXPL: 0CVE-2022-48747 – block: Fix wrong offset in bio_truncate()
https://notcve.org/view.php?id=CVE-2022-48747
In the Linux kernel, the following vulnerability has been resolved: block: Fix wrong offset in bio_truncate() bio_truncate() clears the buffer outside of last block of bdev, however current bio_truncate() is using the wrong offset of page. So it can return the uninitialized data. This happened when both of truncated/corrupted FS and userspace (via bdev) are trying to read the last of bdev. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bloque: corrige el desplazamiento incorrecto en bio_truncate() bio_truncate() borra el búfer fuera del último bloque de bdev, sin embargo, el bio_truncate() actual está usando el desplazamiento de página incorrecto. Entonces puede devolver los datos no inicializados. Esto sucedió cuando tanto el FS truncado/corrupto como el espacio de usuario (a través de bdev) intentaban leer lo último de bdev. • https://git.kernel.org/stable/c/6cbf4c731d7812518cd857c2cfc3da9fd120f6ae https://git.kernel.org/stable/c/b63e120189fd92aff00096d11e2fc5253f60248b https://git.kernel.org/stable/c/4633a79ff8bc82770486a063a08b55e5162521d8 https://git.kernel.org/stable/c/941d5180c430ce5b0f7a3622ef9b76077bfa3d82 https://git.kernel.org/stable/c/3ee859e384d453d6ac68bfd5971f630d9fa46ad3 https://access.redhat.com/security/cve/CVE-2022-48747 https://bugzilla.redhat.com/show_bug.cgi?id=2293312 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') CWE-908: Use of Uninitialized Resource •
CVSS: 5.3EPSS: 0%CPEs: 10EXPL: 0CVE-2022-48743 – net: amd-xgbe: Fix skb data length underflow
https://notcve.org/view.php?id=CVE-2022-48743
In the Linux kernel, the following vulnerability has been resolved: net: amd-xgbe: Fix skb data length underflow There will be BUG_ON() triggered in include/linux/skbuff.h leading to intermittent kernel panic, when the skb length underflow is detected. Fix this by dropping the packet if such length underflows are seen because of inconsistencies in the hardware descriptors. • https://git.kernel.org/stable/c/fafc9555d87a19c78bcd43ed731c3a73bf0b37a9 https://git.kernel.org/stable/c/622c36f143fc9566ba49d7cec994c2da1182d9e2 https://git.kernel.org/stable/c/ae43f9360a21b35cf785ae9a0fdce524d7af0938 https://git.kernel.org/stable/c/ae9d577f3dbb686862b7d0dc9cc73054f0964d4d https://git.kernel.org/stable/c/9924c80bd484340191e586110ca22bff23a49f2e https://git.kernel.org/stable/c/617f9934bb37993b9813832516f318ba874bcb7d https://git.kernel.org/stable/c/34aeb4da20f93ac80a6291a2dbe7b9c6460e9b26 https://git.kernel.org/stable/c/9892742f035f7aa7dcd2bb0750effa486 • CWE-124: Buffer Underwrite ('Buffer Underflow') •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48742 – rtnetlink: make sure to refresh master_dev/m_ops in __rtnl_newlink()
https://notcve.org/view.php?id=CVE-2022-48742
In the Linux kernel, the following vulnerability has been resolved: rtnetlink: make sure to refresh master_dev/m_ops in __rtnl_newlink() While looking at one unrelated syzbot bug, I found the replay logic in __rtnl_newlink() to potentially trigger use-after-free. It is better to clear master_dev and m_ops inside the loop, in case we have to replay it. • https://git.kernel.org/stable/c/ba7d49b1f0f8e5f24294a880ed576964059af5ef https://git.kernel.org/stable/c/2cf180360d66bd657e606c1217e0e668e6faa303 https://git.kernel.org/stable/c/7d9211678c0f0624f74cdff36117ab8316697bb8 https://git.kernel.org/stable/c/a01e60a1ec6bef9be471fb7182a33c6d6f124e93 https://git.kernel.org/stable/c/bd43771ee9759dd9dfae946bff190e2c5a120de5 https://git.kernel.org/stable/c/3bbe2019dd12b8d13671ee6cda055d49637b4c39 https://git.kernel.org/stable/c/def5e7070079b2a214b3b1a2fbec623e6fbfe34a https://git.kernel.org/stable/c/36a9a0aee881940476b254e0352581401 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48740 – selinux: fix double free of cond_list on error paths
https://notcve.org/view.php?id=CVE-2022-48740
In the Linux kernel, the following vulnerability has been resolved: selinux: fix double free of cond_list on error paths On error path from cond_read_list() and duplicate_policydb_cond_list() the cond_list_destroy() gets called a second time in caller functions, resulting in NULL pointer deref. Fix this by resetting the cond_list_len to 0 in cond_list_destroy(), making subsequent calls a noop. Also consistently reset the cond_list pointer to NULL after freeing. [PM: fix line lengths in the description] • https://git.kernel.org/stable/c/f446089a268c8fc6908488e991d28a9b936293db https://git.kernel.org/stable/c/70caa32e6d81f45f0702070c0e4dfe945e92fbd7 https://git.kernel.org/stable/c/7ed9cbf7ac0d4ed86b356e1b944304ae9ee450d4 https://git.kernel.org/stable/c/186edf7e368c40d06cf727a1ad14698ea67b74ad •