CVSS: 6.0EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52529 – HID: sony: Fix a potential memory leak in sony_probe()
https://notcve.org/view.php?id=CVE-2023-52529
In the Linux kernel, the following vulnerability has been resolved: HID: sony: Fix a potential memory leak in sony_probe() If an error occurs after a successful usb_alloc_urb() call, usb_free_urb() should be called. • https://git.kernel.org/stable/c/fb1a79a6b6e1223ddb18f12aa35e36f832da2290 https://git.kernel.org/stable/c/44535bbc811f56c0e241832cc7dcfd3d42221524 https://git.kernel.org/stable/c/02f04a3c5d74bd8842ce1ad44a2304e5b62a238f https://git.kernel.org/stable/c/bb0707fde7492121917fd9ddb43829e96ec0bb9e https://git.kernel.org/stable/c/f237b17611fa3501f43f12d1cb64323e10fdcb4f https://git.kernel.org/stable/c/f566efa7de1e35e6523f4acbaf85068a540be07d https://git.kernel.org/stable/c/e1cd4004cde7c9b694bbdd8def0e02288ee58c74 https://access.redhat.com/security/cve/CVE-2023-52529 • CWE-402: Transmission of Private Resources into a New Sphere ('Resource Leak') •
CVSS: 4.4EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52528 – net: usb: smsc75xx: Fix uninit-value access in __smsc75xx_read_reg
https://notcve.org/view.php?id=CVE-2023-52528
In the Linux kernel, the following vulnerability has been resolved: net: usb: smsc75xx: Fix uninit-value access in __smsc75xx_read_reg syzbot reported the following uninit-value access issue: ===================================================== BUG: KMSAN: uninit-value in smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline] BUG: KMSAN: uninit-value in smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482 CPU: 0 PID: 8696 Comm: kworker/0:3 Not tainted 5.8.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x21c/0x280 lib/dump_stack.c:118 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:121 __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215 smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline] smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482 usbnet_probe+0x1152/0x3f90 drivers/net/usb/usbnet.c:1737 usb_probe_interface+0xece/0x1550 drivers/usb/core/driver.c:374 really_probe+0xf20/0x20b0 drivers/base/dd.c:529 driver_probe_device+0x293/0x390 drivers/base/dd.c:701 __device_attach_driver+0x63f/0x830 drivers/base/dd.c:807 bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431 __device_attach+0x4e2/0x7f0 drivers/base/dd.c:873 device_initial_probe+0x4a/0x60 drivers/base/dd.c:920 bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491 device_add+0x3b0e/0x40d0 drivers/base/core.c:2680 usb_set_configuration+0x380f/0x3f10 drivers/usb/core/message.c:2032 usb_generic_driver_probe+0x138/0x300 drivers/usb/core/generic.c:241 usb_probe_device+0x311/0x490 drivers/usb/core/driver.c:272 really_probe+0xf20/0x20b0 drivers/base/dd.c:529 driver_probe_device+0x293/0x390 drivers/base/dd.c:701 __device_attach_driver+0x63f/0x830 drivers/base/dd.c:807 bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431 __device_attach+0x4e2/0x7f0 drivers/base/dd.c:873 device_initial_probe+0x4a/0x60 drivers/base/dd.c:920 bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491 device_add+0x3b0e/0x40d0 drivers/base/core.c:2680 usb_new_device+0x1bd4/0x2a30 drivers/usb/core/hub.c:2554 hub_port_connect drivers/usb/core/hub.c:5208 [inline] hub_port_connect_change drivers/usb/core/hub.c:5348 [inline] port_event drivers/usb/core/hub.c:5494 [inline] hub_event+0x5e7b/0x8a70 drivers/usb/core/hub.c:5576 process_one_work+0x1688/0x2140 kernel/workqueue.c:2269 worker_thread+0x10bc/0x2730 kernel/workqueue.c:2415 kthread+0x551/0x590 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293 Local variable ----buf.i87@smsc75xx_bind created at: __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline] smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline] smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482 __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline] smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline] smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482 This issue is caused because usbnet_read_cmd() reads less bytes than requested (zero byte in the reproducer). In this case, 'buf' is not properly filled. This patch fixes the issue by returning -ENODATA if usbnet_read_cmd() reads less bytes than requested. • https://git.kernel.org/stable/c/d0cad871703b898a442e4049c532ec39168e5b57 https://git.kernel.org/stable/c/3e0af6eec1789fd11934164a7f4dbcad979855a4 https://git.kernel.org/stable/c/2a36d9e2995c8c3c3f179aab1215a69cff06cbed https://git.kernel.org/stable/c/310f1c92f65ad905b7e81fe14de82d979ebbd825 https://git.kernel.org/stable/c/30bc4d7aebe33904b0f2d3aad4b4a9c6029ad0c5 https://git.kernel.org/stable/c/cda10784a176d7192f08ecb518f777a4e9575812 https://git.kernel.org/stable/c/9ffc5018020fe646795a8dc1203224b8f776dc09 https://git.kernel.org/stable/c/4931e80da9463b03bfe42be54a9a19f21 • CWE-252: Unchecked Return Value •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52527 – ipv4, ipv6: Fix handling of transhdrlen in __ip{,6}_append_data()
https://notcve.org/view.php?id=CVE-2023-52527
In the Linux kernel, the following vulnerability has been resolved: ipv4, ipv6: Fix handling of transhdrlen in __ip{,6}_append_data() Including the transhdrlen in length is a problem when the packet is partially filled (e.g. something like send(MSG_MORE) happened previously) when appending to an IPv4 or IPv6 packet as we don't want to repeat the transport header or account for it twice. This can happen under some circumstances, such as splicing into an L2TP socket. The symptom observed is a warning in __ip6_append_data(): WARNING: CPU: 1 PID: 5042 at net/ipv6/ip6_output.c:1800 __ip6_append_data.isra.0+0x1be8/0x47f0 net/ipv6/ip6_output.c:1800 that occurs when MSG_SPLICE_PAGES is used to append more data to an already partially occupied skbuff. The warning occurs when 'copy' is larger than the amount of data in the message iterator. This is because the requested length includes the transport header length when it shouldn't. This can be triggered by, for example: sfd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_L2TP); bind(sfd, ...); // ::1 connect(sfd, ...); // ::1 port 7 send(sfd, buffer, 4100, MSG_MORE); sendfile(sfd, dfd, NULL, 1024); Fix this by only adding transhdrlen into the length if the write queue is empty in l2tp_ip6_sendmsg(), analogously to how UDP does things. l2tp_ip_sendmsg() looks like it won't suffer from this problem as it builds the UDP packet itself. • https://git.kernel.org/stable/c/a32e0eec7042b21ccb52896cf715e3e2641fed93 https://git.kernel.org/stable/c/7626b9fed53092aa2147978070e610ecb61af844 https://git.kernel.org/stable/c/559d697c5d072593d22b3e0bd8b8081108aeaf59 https://git.kernel.org/stable/c/1fc793d68d50dee4782ef2e808913d5dd880bcc6 https://git.kernel.org/stable/c/96b2e1090397217839fcd6c9b6d8f5d439e705ed https://git.kernel.org/stable/c/cd1189956393bf850b2e275e37411855d3bd86bb https://git.kernel.org/stable/c/f6a7182179c0ed788e3755ee2ed18c888ddcc33f https://git.kernel.org/stable/c/fe80658c08e3001c80c5533cd41abfbb0 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2023-52526 – erofs: fix memory leak of LZMA global compressed deduplication
https://notcve.org/view.php?id=CVE-2023-52526
In the Linux kernel, the following vulnerability has been resolved: erofs: fix memory leak of LZMA global compressed deduplication When stressing microLZMA EROFS images with the new global compressed deduplication feature enabled (`-Ededupe`), I found some short-lived temporary pages weren't properly released, which could slowly cause unexpected OOMs hours later. Let's fix it now (LZ4 and DEFLATE don't have this issue.) • https://git.kernel.org/stable/c/5c2a64252c5dc4cfe78e5b2a531c118894e3d155 https://git.kernel.org/stable/c/6a5a8f0a9740f865693d5aa97a42cc4504538e18 https://git.kernel.org/stable/c/c955751cbf864cf2055117dd3fe7f780d2a57b56 https://git.kernel.org/stable/c/75a5221630fe5aa3fedba7a06be618db0f79ba1e •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52525 – wifi: mwifiex: Fix oob check condition in mwifiex_process_rx_packet
https://notcve.org/view.php?id=CVE-2023-52525
In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Fix oob check condition in mwifiex_process_rx_packet Only skip the code path trying to access the rfc1042 headers when the buffer is too small, so the driver can still process packets without rfc1042 headers. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mwifiex: corrige la condición de verificación de oob en mwifiex_process_rx_packet Solo omita la ruta del código al intentar acceder a los encabezados rfc1042 cuando el búfer sea demasiado pequeño, para que el controlador aún pueda procesar paquetes sin encabezados rfc1042 . • https://git.kernel.org/stable/c/f517c97fc129995de77dd06aa5a74f909ebf568f https://git.kernel.org/stable/c/8824aa4ab62c800f75d96f48e1883a5f56ec5869 https://git.kernel.org/stable/c/29eca8b7863d1d7de6c5b746b374e3487d14f154 https://git.kernel.org/stable/c/3fe3923d092e22d87d1ed03e2729db444b8c1331 https://git.kernel.org/stable/c/7c54b6fc39eb1aac51cf2945f8a25e2a47fdca02 https://git.kernel.org/stable/c/3975e21d4d01efaf0296ded40d11c06589c49245 https://git.kernel.org/stable/c/650d1bc02fba7b42f476d8b6643324abac5921ed https://git.kernel.org/stable/c/a7300e3800e9fd5405e88ce67709c1a97 •