CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2022-48952 – PCI: mt7621: Add sentinel to quirks table
https://notcve.org/view.php?id=CVE-2022-48952
In the Linux kernel, the following vulnerability has been resolved: PCI: mt7621: Add sentinel to quirks table Current driver is missing a sentinel in the struct soc_device_attribute array, which causes an oops when assessed by the soc_device_match(mt7621_pcie_quirks_match) call. This was only exposed once the CONFIG_SOC_MT7621 mt7621 soc_dev_attr was fixed to register the SOC as a device, in: commit 7c18b64bba3b ("mips: ralink: mt7621: do not use kzalloc too early") Fix it by adding the required sentinel. • https://git.kernel.org/stable/c/b483b4e4d3f6bfd5089b9e6dc9ba259879c6ce6f https://git.kernel.org/stable/c/21fd877300b01d25c5807c327848fdc7c813cf0e https://git.kernel.org/stable/c/3e9c395ef2d52975b2c2894d2da09d6db2958bc6 https://git.kernel.org/stable/c/cb7323ece786f243f6d6ccf2e5b2b27b736bdc04 https://git.kernel.org/stable/c/a4997bae1b5b012c8a6e2643e26578a7bc2cae36 https://git.kernel.org/stable/c/19098934f910b4d47cb30251dd39ffa57bef9523 •
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 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48949 – igb: Initialize mailbox message for VF reset
https://notcve.org/view.php?id=CVE-2022-48949
In the Linux kernel, the following vulnerability has been resolved: igb: Initialize mailbox message for VF reset When a MAC address is not assigned to the VF, that portion of the message sent to the VF is not set. The memory, however, is allocated from the stack meaning that information may be leaked to the VM. Initialize the message buffer to 0 so that no information is passed to the VM in this case. • https://git.kernel.org/stable/c/6ddbc4cf1f4d5a3a58b4223c80881f299dae3774 https://git.kernel.org/stable/c/a6629659af3f5c6a91e3914ea62554c975ab77f4 https://git.kernel.org/stable/c/ef1d739dd1f362aec081278ff92f943c31eb177a https://git.kernel.org/stable/c/c581439a977545d61849a72e8ed631cfc8a2a3c1 https://git.kernel.org/stable/c/f2479c3daaabccbac6c343a737615d0c595c6dc4 https://git.kernel.org/stable/c/367e1e3399dbc56fc669740c4ab60e35da632b0e https://git.kernel.org/stable/c/51fd5ede7ed42f272682a0c33d6f0767b3484a3d https://git.kernel.org/stable/c/c383c7c35c7bc15e07a04eefa060a8a80 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2022-48948 – usb: gadget: uvc: Prevent buffer overflow in setup handler
https://notcve.org/view.php?id=CVE-2022-48948
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: Prevent buffer overflow in setup handler Setup function uvc_function_setup permits control transfer requests with up to 64 bytes of payload (UVC_MAX_REQUEST_SIZE), data stage handler for OUT transfer uses memcpy to copy req->actual bytes to uvc_event->data.data array of size 60. This may result in an overflow of 4 bytes. • https://git.kernel.org/stable/c/cdda479f15cd13fa50a913ca85129c0437cc7b91 https://git.kernel.org/stable/c/4972e3528b968665b596b5434764ff8fd9446d35 https://git.kernel.org/stable/c/06fd17ee92c8f1704c7e54ec0fd50ae0542a49a5 https://git.kernel.org/stable/c/bc8380fe5768c564f921f7b4eaba932e330b9e4b https://git.kernel.org/stable/c/b8fb1cba934ea122b50f13a4f9d6fc4fdc43d2be https://git.kernel.org/stable/c/c79538f32df12887f110dcd6b9c825b482905f24 https://git.kernel.org/stable/c/6b41a35b41f77821db24f2d8f66794b390a585c5 https://git.kernel.org/stable/c/7b1f773277a72f9756d47a41b94e43506 •