Page 10 of 7301 results (0.010 seconds)

CVSS: 5.5EPSS: %CPEs: 2EXPL: 0

20 May 2025 — In the Linux kernel, the following vulnerability has been resolved: powerpc64/ftrace: fix module loading without patchable function entries get_stubs_size assumes that there must always be at least one patchable function entry, which is not always the case (modules that export data but no code), otherwise it returns -ENOEXEC and thus the section header sh_size is set to that value. During module_memory_alloc() the size is passed to execmem_alloc() after being page-aligned and thus set to zero which will cau... • https://git.kernel.org/stable/c/eec37961a56aa4f3fe1c33ffd48eec7d1bb0c009 •

CVSS: 6.6EPSS: %CPEs: 5EXPL: 0

20 May 2025 — In the Linux kernel, the following vulnerability has been resolved: wifi: plfxlc: Remove erroneous assert in plfxlc_mac_release plfxlc_mac_release() asserts that mac->lock is held. This assertion is incorrect, because even if it was possible, it would not be the valid behaviour. The function is used when probe fails or after the device is disconnected. In both cases mac->lock can not be held as the driver is not working with the device at the moment. All functions that use mac->lock unlock it just after it ... • https://git.kernel.org/stable/c/68d57a07bfe5bb29b80cd8b8fa24c9d1ea104124 •

CVSS: 5.5EPSS: %CPEs: 3EXPL: 0

20 May 2025 — In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix error handling path in bnxt_init_chip() WARN_ON() is triggered in __flush_work() if bnxt_init_chip() fails because we call cancel_work_sync() on dim work that has not been initialized. WARNING: CPU: 37 PID: 5223 at kernel/workqueue.c:4201 __flush_work.isra.0+0x212/0x230 The driver relies on the BNXT_STATE_NAPI_DISABLED bit to check if dim work has already been cancelled. But in the bnxt_open() path, BNXT_STATE_NAPI_DISABLED is ... • https://git.kernel.org/stable/c/f697217f980ffc796c72c34dbf7d59a6b1996888 •

CVSS: 5.5EPSS: %CPEs: 3EXPL: 0

20 May 2025 — In the Linux kernel, the following vulnerability has been resolved: net: use sock_gen_put() when sk_state is TCP_TIME_WAIT It is possible for a pointer of type struct inet_timewait_sock to be returned from the functions __inet_lookup_established() and __inet6_lookup_established(). This can cause a crash when the returned pointer is of type struct inet_timewait_sock and sock_put() is called on it. The following is a crash call stack that shows sk->sk_wmem_alloc being accessed in sk_free() during the call to ... • https://git.kernel.org/stable/c/c9d1d23e5239f41700be69133a5769ac5ebc88a8 •

CVSS: 5.5EPSS: 0%CPEs: 9EXPL: 0

20 May 2025 — In the Linux kernel, the following vulnerability has been resolved: mtd: inftlcore: Add error check for inftl_read_oob() In INFTL_findwriteunit(), the return value of inftl_read_oob() need to be checked. A proper implementation can be found in INFTL_deleteblock(). The status will be set as SECTOR_IGNORE to break from the while-loop correctly if the inftl_read_oob() fails. In the Linux kernel, the following vulnerability has been resolved: mtd: inftlcore: Add error check for inftl_read_oob() In INFTL_findwri... • https://git.kernel.org/stable/c/8593fbc68b0df1168995de76d1af38eb62fd6b62 •

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

19 May 2025 — In the Linux kernel, the following vulnerability has been resolved: ALSA: ump: Fix buffer overflow at UMP SysEx message conversion The conversion function from MIDI 1.0 to UMP packet contains an internal buffer to keep the incoming MIDI bytes, and its size is 4, as it was supposed to be the max size for a MIDI1 UMP packet data. However, the implementation overlooked that SysEx is handled in a different format, and it can be up to 6 bytes, as found in do_convert_to_ump(). It leads eventually to a buffer over... • https://git.kernel.org/stable/c/0b5288f5fe63eab687c14e5940b9e0d532b129f2 •

CVSS: 7.8EPSS: 0%CPEs: 6EXPL: 0

16 May 2025 — In the Linux kernel, the following vulnerability has been resolved: net_sched: hfsc: Fix a UAF vulnerability in class with netem as child qdisc As described in Gerrard's report [1], we have a UAF case when an hfsc class has a netem child qdisc. The crux of the issue is that hfsc is assuming that checking for cl->qdisc->q.qlen == 0 guarantees that it hasn't inserted the class in the vttree or eltree (which is not true for the netem duplicate case). This patch checks the n_active class variable to make sure t... • https://git.kernel.org/stable/c/37d9cf1a3ce35de3df6f7d209bfb1f50cf188cea •

CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0

14 May 2025 — In the Linux kernel, the following vulnerability has been resolved: media: dw2102: Fix null-ptr-deref in dw2102_i2c_transfer() In dw2102_i2c_transfer, msg is controlled by user. When msg[i].buf is null and msg[i].len is zero, former checks on msg[i].buf would be passed. Malicious data finally reach dw2102_i2c_transfer. If accessing msg[i].buf[0] without sanity check, null ptr deref would happen. We add check on msg[i].len to prevent crash. Similar commit: commit 950e252cb469 ("[media] dw2102: limit messages... • https://git.kernel.org/stable/c/77cbd42d29de9ffc93d5529bab8813cde53af14c •

CVSS: 7.1EPSS: 0%CPEs: 7EXPL: 0

10 May 2025 — In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btsdio: fix use after free bug in btsdio_remove due to race condition In btsdio_probe, the data->work is bound with btsdio_work. It will be started in btsdio_send_frame. If the btsdio_remove runs with a unfinished work, there may be a race condition that hdev is freed but used in btsdio_work. Fix it by canceling the work before do cleanup in btsdio_remove. In the Linux kernel, the following vulnerability has been resolved: Blueto... • https://git.kernel.org/stable/c/6c3653627397a0d6eab19b20a59423e118985a6b •

CVSS: 7.1EPSS: 0%CPEs: 6EXPL: 0

09 May 2025 — In the Linux kernel, the following vulnerability has been resolved: ASoC: ops: Consistently treat platform_max as control value This reverts commit 9bdd10d57a88 ("ASoC: ops: Shift tested values in snd_soc_put_volsw() by +min"), and makes some additional related updates. There are two ways the platform_max could be interpreted; the maximum register value, or the maximum value the control can be set to. The patch moved from treating the value as a control value to a register one. When the patch was applied it... • https://git.kernel.org/stable/c/c11fc224e58e7972ffd05b8f25e9b1d6a0b8d562 •