Page 232 of 3334 results (0.014 seconds)

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

25 Mar 2024 — In the Linux kernel, the following vulnerability has been resolved: net: usb: fix memory leak in smsc75xx_bind Syzbot reported memory leak in smsc75xx_bind(). The problem was is non-freed memory in case of errors after memory allocation. backtrace: [] kmalloc include/linux/slab.h:556 [inline] [] kzalloc include/linux/slab.h:686 [inline] [] smsc75xx_bind+0x7a/0x334 drivers/net/usb/smsc75xx.c:1460 [] usbnet_probe+0x3b6/0xc30 dr... • https://git.kernel.org/stable/c/d0cad871703b898a442e4049c532ec39168e5b57 • CWE-401: Missing Release of Memory after Effective Lifetime CWE-402: Transmission of Private Resources into a New Sphere ('Resource Leak') •

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

25 Mar 2024 — In the Linux kernel, the following vulnerability has been resolved: USB: usbfs: Don't WARN about excessively large memory allocations Syzbot found that the kernel generates a WARNing if the user tries to submit a bulk transfer through usbfs with a buffer that is way too large. This isn't a bug in the kernel; it's merely an invalid request from the user and the usbfs code does handle it correctly. In theory the same thing can happen with async transfers, or with the packet descriptor table for isochronou... • https://git.kernel.org/stable/c/2ab21d6e1411999b5fb43434f421f00bf50002eb •

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

25 Mar 2024 — In the Linux kernel, the following vulnerability has been resolved: serial: rp2: use 'request_firmware' instead of 'request_firmware_nowait' In 'rp2_probe', the driver registers 'rp2_uart_interrupt' then calls 'rp2_fw_cb' through 'request_firmware_nowait'. In 'rp2_fw_cb', if the firmware don't exists, function just return without initializing ports of 'rp2_card'. But now the interrupt handler function has been registered, and when an interrupt comes, 'rp2_uart_interrupt' may access those ports then causin... • https://git.kernel.org/stable/c/1e04d5d5fe5e76af68f834e1941fcbfa439653be •

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

25 Mar 2024 — In the Linux kernel, the following vulnerability has been resolved: NFS: fix an incorrect limit in filelayout_decode_layout() The "sizeof(struct nfs_fh)" is two bytes too large and could lead to memory corruption. It should be NFS_MAXFHSIZE because that's the size of the ->data[] buffer. I reversed the size of the arguments to put the variable on the left. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFS: corrige un límite incorrecto en filelayout_decode_layout() El "sizeof(struct ... • https://git.kernel.org/stable/c/16b374ca439fb406e46e071f75428f5b033056f8 •

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

25 Mar 2024 — In the Linux kernel, the following vulnerability has been resolved: NFS: Fix an Oopsable condition in __nfs_pageio_add_request() Ensure that nfs_pageio_error_cleanup() resets the mirror array contents, so that the structure reflects the fact that it is now empty. Also change the test in nfs_pageio_do_add_request() to be more robust by checking whether or not the list is empty rather than relying on the value of pg_count. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: NFS: corrija una cond... • https://git.kernel.org/stable/c/a7d42ddb3099727f58366fa006f850a219cce6c8 •

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

25 Mar 2024 — In the Linux kernel, the following vulnerability has been resolved: NFS: Don't corrupt the value of pg_bytes_written in nfs_do_recoalesce() The value of mirror->pg_bytes_written should only be updated after a successful attempt to flush out the requests on the list. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: NFS: no corrompa el valor de pg_bytes_writing en nfs_do_recoalesce() El valor de mirror->pg_bytes_write solo debe actualizarse después de un intento exitoso de eliminar las sol... • https://git.kernel.org/stable/c/a7d42ddb3099727f58366fa006f850a219cce6c8 •

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

25 Mar 2024 — In the Linux kernel, the following vulnerability has been resolved: drm/meson: fix shutdown crash when component not probed When main component is not probed, by example when the dw-hdmi module is not loaded yet or in probe defer, the following crash appears on shutdown: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000038 ... pc : meson_drv_shutdown+0x24/0x50 lr : platform_drv_shutdown+0x20/0x30 ... Call trace: meson_drv_shutdown+0x24/0x50 platform_drv_shutdown+0x20/0x30 ... • https://git.kernel.org/stable/c/8a5160cc8488776ddc48ea045860dab015f47390 •

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

25 Mar 2024 — In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix null deref accessing lag dev It could be the lag dev is null so stop processing the event. In bond_enslave() the active/backup slave being set before setting the upper dev so first event is without an upper dev. After setting the upper dev with bond_master_upper_dev_link() there is a second event and in that event we have an upper dev. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/mlx5e: corrigió el de... • https://git.kernel.org/stable/c/7e51891a237f9ea319f53f9beb83afb0077d88e6 • CWE-476: NULL Pointer Dereference •

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

25 Mar 2024 — In the Linux kernel, the following vulnerability has been resolved: tipc: wait and exit until all work queues are done On some host, a crash could be triggered simply by repeating these commands several times: # modprobe tipc # tipc bearer enable media udp name UDP1 localip 127.0.0.1 # rmmod tipc [] BUG: unable to handle kernel paging request at ffffffffc096bb00 [] Workqueue: events 0xffffffffc096bb00 [] Call Trace: [] ? process_one_work+0x1a7/0x360 [] ? worker_thread+0x30/0x390 [] ... • https://git.kernel.org/stable/c/d0f91938bede204a343473792529e0db7d599836 •

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

25 Mar 2024 — In the Linux kernel, the following vulnerability has been resolved: tipc: skb_linearize the head skb when reassembling msgs It's not a good idea to append the frag skb to a skb's frag_list if the frag_list already has skbs from elsewhere, such as this skb was created by pskb_copy() where the frag_list was cloned (all the skbs in it were skb_get'ed) and shared by multiple skbs. However, the new appended frag skb should have been only seen by the current skb. Otherwise, it will cause use after free crashes... • https://git.kernel.org/stable/c/45c8b7b175ceb2d542e0fe15247377bf3bce29ec •