Page 9 of 3258 results (0.005 seconds)

CVSS: -EPSS: 0%CPEs: 4EXPL: 0

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: 0

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: 0

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: 0

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: 0

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 •