CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48967 – NFC: nci: Bounds check struct nfc_target arrays
https://notcve.org/view.php?id=CVE-2022-48967
In the Linux kernel, the following vulnerability has been resolved: NFC: nci: Bounds check struct nfc_target arrays While running under CONFIG_FORTIFY_SOURCE=y, syzkaller reported: memcpy: detected field-spanning write (size 129) of single field "target->sensf_res" at net/nfc/nci/ntf.c:260 (size 18) This appears to be a legitimate lack of bounds checking in nci_add_new_protocol(). Add the missing checks. • https://git.kernel.org/stable/c/019c4fbaa790e2b3f11dab0c8b7d9896d77db3e5 https://git.kernel.org/stable/c/6b37f0dc0638d13a006f2f24d2f6ca61e83bc714 https://git.kernel.org/stable/c/dbdcfb9f6748218a149f62468d6297ce3f014e9c https://git.kernel.org/stable/c/cff35329070b96b4484d23f9f48a5ca2c947e750 https://git.kernel.org/stable/c/6778434706940b8fad7ef35f410d2b9929f256d2 https://git.kernel.org/stable/c/27eb2d7a1b9987b6d0429b7716b1ff3b82c4ffc9 https://git.kernel.org/stable/c/908b2da426fe9c3ce74cf541ba40e7a4251db191 https://git.kernel.org/stable/c/f41547546db9af99da2c34e3368664d7a •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48958 – ethernet: aeroflex: fix potential skb leak in greth_init_rings()
https://notcve.org/view.php?id=CVE-2022-48958
In the Linux kernel, the following vulnerability has been resolved: ethernet: aeroflex: fix potential skb leak in greth_init_rings() The greth_init_rings() function won't free the newly allocated skb when dma_mapping_error() returns error, so add dev_kfree_skb() to fix it. Compile tested only. • https://git.kernel.org/stable/c/d4c41139df6e74c6fff0cbac43e51cab782133be https://git.kernel.org/stable/c/223654e2e2c8d05347cd8e300f8d1ec6023103dd https://git.kernel.org/stable/c/cb1e293f858e5e1152b8791047ed4bdaaf392189 https://git.kernel.org/stable/c/bfaa8f6c5b84b295dd73b0138b57c5555ca12b1c https://git.kernel.org/stable/c/99669d94ce145389f1d6f197e6e18ed50d43fb76 https://git.kernel.org/stable/c/87277bdf2c370ab2d07cfe77dfa9b37f82bbe1e5 https://git.kernel.org/stable/c/c7adcbd0fd3fde1b19150c3e955fb4a30c5bd9b7 https://git.kernel.org/stable/c/dd62867a6383f78f75f07039394aac259 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48953 – rtc: cmos: Fix event handler registration ordering issue
https://notcve.org/view.php?id=CVE-2022-48953
In the Linux kernel, the following vulnerability has been resolved: rtc: cmos: Fix event handler registration ordering issue Because acpi_install_fixed_event_handler() enables the event automatically on success, it is incorrect to call it before the handler routine passed to it is ready to handle events. Unfortunately, the rtc-cmos driver does exactly the incorrect thing by calling cmos_wake_setup(), which passes rtc_handler() to acpi_install_fixed_event_handler(), before cmos_do_probe(), because rtc_handler() uses dev_get_drvdata() to get to the cmos object pointer and the driver data pointer is only populated in cmos_do_probe(). This leads to a NULL pointer dereference in rtc_handler() on boot if the RTC fixed event happens to be active at the init time. To address this issue, change the initialization ordering of the driver so that cmos_wake_setup() is always called after a successful cmos_do_probe() call. While at it, change cmos_pnp_probe() to call cmos_do_probe() after the initial if () statement used for computing the IRQ argument to be passed to cmos_do_probe() which is cleaner than calling it in each branch of that if () (local variable "irq" can be of type int, because it is passed to that function as an argument of type int). Note that commit 6492fed7d8c9 ("rtc: rtc-cmos: Do not check ACPI_FADT_LOW_POWER_S0") caused this issue to affect a larger number of systems, because previously it only affected systems with ACPI_FADT_LOW_POWER_S0 set, but it is present regardless of that commit. • https://git.kernel.org/stable/c/a474aaedac99ba86e28ef6c912a7647c482db6dd https://git.kernel.org/stable/c/0bcfccb48696aba475f046c2021f0733659ce0ef https://git.kernel.org/stable/c/60c6e563a843032cf6ff84b2fb732cd8754fc10d https://git.kernel.org/stable/c/1ba745fce13d19775100eece30b0bfb8b8b10ea6 https://git.kernel.org/stable/c/4919d3eb2ec0ee364f7e3cf2d99646c1b224fae8 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48951 – ASoC: ops: Check bounds for second channel in snd_soc_put_volsw_sx()
https://notcve.org/view.php?id=CVE-2022-48951
In the Linux kernel, the following vulnerability has been resolved: ASoC: ops: Check bounds for second channel in snd_soc_put_volsw_sx() The bounds checks in snd_soc_put_volsw_sx() are only being applied to the first channel, meaning it is possible to write out of bounds values to the second channel in stereo controls. Add appropriate checks. • https://git.kernel.org/stable/c/56288987843c3cb343e81e5fa51549cbaf541bd0 https://git.kernel.org/stable/c/cf1c225f1927891ae388562b78ced7840c3723b9 https://git.kernel.org/stable/c/18a168d85eadcfd45f015b5ecd2a97801b959e43 https://git.kernel.org/stable/c/9796d07c753164b7e6b0d7ef23fb4482840a9ef8 https://git.kernel.org/stable/c/50b5f6d4d9d2d69a7498c44fd8b26e13d73d3d98 https://git.kernel.org/stable/c/cf611d786796ec33da09d8c83d7d7f4e557b27de https://git.kernel.org/stable/c/1798b62d642e7b3d4ea3403914c3caf4e438465d https://git.kernel.org/stable/c/97eea946b93961fffd29448dcda7398d0 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2022-48950 – perf: Fix perf_pending_task() UaF
https://notcve.org/view.php?id=CVE-2022-48950
In the Linux kernel, the following vulnerability has been resolved: perf: Fix perf_pending_task() UaF Per syzbot it is possible for perf_pending_task() to run after the event is free()'d. There are two related but distinct cases: - the task_work was already queued before destroying the event; - destroying the event itself queues the task_work. The first cannot be solved using task_work_cancel() since perf_release() itself might be called from a task_work (____fput), which means the current->task_works list is already empty and task_work_cancel() won't be able to find the perf_pending_task() entry. The simplest alternative is extending the perf_event lifetime to cover the task_work. The second is just silly, queueing a task_work while you know the event is going away makes no sense and is easily avoided by re-arranging how the event is marked STATE_DEAD and ensuring it goes through STATE_OFF on the way down. • https://git.kernel.org/stable/c/8bffa95ac19ff27c8261904f89d36c7fcf215d59 https://git.kernel.org/stable/c/78e1317a174edbfd1182599bf76c092a2877672c https://git.kernel.org/stable/c/517e6a301f34613bff24a8e35b5455884f2d83d8 •