Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: u_serial: Add null pointer check in gserial_suspend<br /> <br /> Consider a case where gserial_disconnect has already cleared<br /> gser-&gt;ioport. And if gserial_suspend gets called afterwards,<br /> it will lead to accessing of gser-&gt;ioport and thus causing<br /> null pointer dereference.<br /> <br /> Avoid this by adding a null pointer check. Added a static<br /> spinlock to prevent gser-&gt;ioport from becoming null after<br /> the newly added null pointer check.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/raid10: check slab-out-of-bounds in md_bitmap_get_counter<br /> <br /> If we write a large number to md/bitmap_set_bits, md_bitmap_checkpage()<br /> will return -EINVAL because &amp;#39;page &gt;= bitmap-&gt;pages&amp;#39;, but the return value<br /> was not checked immediately in md_bitmap_get_counter() in order to set<br /> *blocks value and slab-out-of-bounds occurs.<br /> <br /> Move check of &amp;#39;page &gt;= bitmap-&gt;pages&amp;#39; to md_bitmap_get_counter() and<br /> return directly if true.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix racy issue under cocurrent smb2 tree disconnect<br /> <br /> There is UAF issue under cocurrent smb2 tree disconnect.<br /> This patch introduce TREE_CONN_EXPIRE flags for tcon to avoid cocurrent<br /> access.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> icmp6: Fix null-ptr-deref of ip6_null_entry-&gt;rt6i_idev in icmp6_dev().<br /> <br /> With some IPv6 Ext Hdr (RPL, SRv6, etc.), we can send a packet that<br /> has the link-local address as src and dst IP and will be forwarded to<br /> an external IP in the IPv6 Ext Hdr.<br /> <br /> For example, the script below generates a packet whose src IP is the<br /> link-local address and dst is updated to 11::.<br /> <br /> # for f in $(find /proc/sys/net/ -name *seg6_enabled*); do echo 1 &gt; $f; done<br /> # python3<br /> &gt;&gt;&gt; from socket import *<br /> &gt;&gt;&gt; from scapy.all import *<br /> &gt;&gt;&gt;<br /> &gt;&gt;&gt; SRC_ADDR = DST_ADDR = "fe80::5054:ff:fe12:3456"<br /> &gt;&gt;&gt;<br /> &gt;&gt;&gt; pkt = IPv6(src=SRC_ADDR, dst=DST_ADDR)<br /> &gt;&gt;&gt; pkt /= IPv6ExtHdrSegmentRouting(type=4, addresses=["11::", "22::"], segleft=1)<br /> &gt;&gt;&gt;<br /> &gt;&gt;&gt; sk = socket(AF_INET6, SOCK_RAW, IPPROTO_RAW)<br /> &gt;&gt;&gt; sk.sendto(bytes(pkt), (DST_ADDR, 0))<br /> <br /> For such a packet, we call ip6_route_input() to look up a route for the<br /> next destination in these three functions depending on the header type.<br /> <br /> * ipv6_rthdr_rcv()<br /> * ipv6_rpl_srh_rcv()<br /> * ipv6_srh_rcv()<br /> <br /> If no route is found, ip6_null_entry is set to skb, and the following<br /> dst_input(skb) calls ip6_pkt_drop().<br /> <br /> Finally, in icmp6_dev(), we dereference skb_rt6_info(skb)-&gt;rt6i_idev-&gt;dev<br /> as the input device is the loopback interface. Then, we have to check if<br /> skb_rt6_info(skb)-&gt;rt6i_idev is NULL or not to avoid NULL pointer deref<br /> for ip6_null_entry.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> PF: supervisor read access in kernel mode<br /> PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] PREEMPT SMP PTI<br /> CPU: 0 PID: 157 Comm: python3 Not tainted 6.4.0-11996-gb121d614371c #35<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:icmp6_send (net/ipv6/icmp.c:436 net/ipv6/icmp.c:503)<br /> Code: fe ff ff 48 c7 40 30 c0 86 5d 83 e8 c6 44 1c 00 e9 c8 fc ff ff 49 8b 46 58 48 83 e0 fe 0f 84 4a fb ff ff 48 8b 80 d0 00 00 00 8b 00 44 8b 88 e0 00 00 00 e9 34 fb ff ff 4d 85 ed 0f 85 69 01<br /> RSP: 0018:ffffc90000003c70 EFLAGS: 00000286<br /> RAX: 0000000000000000 RBX: 0000000000000001 RCX: 00000000000000e0<br /> RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff888006d72a18<br /> RBP: ffffc90000003d80 R08: 0000000000000000 R09: 0000000000000001<br /> R10: ffffc90000003d98 R11: 0000000000000040 R12: ffff888006d72a10<br /> R13: 0000000000000000 R14: ffff8880057fb800 R15: ffffffff835d86c0<br /> FS: 00007f9dc72ee740(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000000 CR3: 00000000057b2000 CR4: 00000000007506f0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ip6_pkt_drop (net/ipv6/route.c:4513)<br /> ipv6_rthdr_rcv (net/ipv6/exthdrs.c:640 net/ipv6/exthdrs.c:686)<br /> ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:437 (discriminator 5))<br /> ip6_input_finish (./include/linux/rcupdate.h:781 net/ipv6/ip6_input.c:483)<br /> __netif_receive_skb_one_core (net/core/dev.c:5455)<br /> process_backlog (./include/linux/rcupdate.h:781 net/core/dev.c:5895)<br /> __napi_poll (net/core/dev.c:6460)<br /> net_rx_action (net/core/dev.c:6529 net/core/dev.c:6660)<br /> __do_softirq (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/irq.h:142 kernel/softirq.c:554)<br /> do_softirq (kernel/softirq.c:454 kernel/softirq.c:441)<br /> <br /> <br /> __local_bh_enable_ip (kernel/softirq.c:381)<br /> __dev_queue_xmit (net/core/dev.c:4231)<br /> ip6_finish_output2 (./include/net/neighbour.h:544 net/ipv6/ip6_output.c:135)<br /> rawv6_sendmsg (./include/net/dst.h:458 ./include/linux/netfilter.h:303 net/ipv6/raw.c:656 net/ipv6/raw.c:914)<br /> sock_sendmsg (net/socket.c:725 net/socket.c:748)<br /> __sys_sendto (net/socket.c:2134)<br /> __x64_sys_sendto (net/socket.c:2146 net/socket.c:2142 net/socket.c:2142)<br /> do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)<br /> RIP: 0033:0x7f9dc751baea<br /> Code: d8 64 89 02 48 c7 c0 ff f<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: bcm: bcm_tx_setup(): fix KMSAN uninit-value in vfs_write<br /> <br /> Syzkaller reported the following issue:<br /> <br /> =====================================================<br /> BUG: KMSAN: uninit-value in aio_rw_done fs/aio.c:1520 [inline]<br /> BUG: KMSAN: uninit-value in aio_write+0x899/0x950 fs/aio.c:1600<br /> aio_rw_done fs/aio.c:1520 [inline]<br /> aio_write+0x899/0x950 fs/aio.c:1600<br /> io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019<br /> __do_sys_io_submit fs/aio.c:2078 [inline]<br /> __se_sys_io_submit+0x293/0x770 fs/aio.c:2048<br /> __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Uninit was created at:<br /> slab_post_alloc_hook mm/slab.h:766 [inline]<br /> slab_alloc_node mm/slub.c:3452 [inline]<br /> __kmem_cache_alloc_node+0x71f/0xce0 mm/slub.c:3491<br /> __do_kmalloc_node mm/slab_common.c:967 [inline]<br /> __kmalloc+0x11d/0x3b0 mm/slab_common.c:981<br /> kmalloc_array include/linux/slab.h:636 [inline]<br /> bcm_tx_setup+0x80e/0x29d0 net/can/bcm.c:930<br /> bcm_sendmsg+0x3a2/0xce0 net/can/bcm.c:1351<br /> sock_sendmsg_nosec net/socket.c:714 [inline]<br /> sock_sendmsg net/socket.c:734 [inline]<br /> sock_write_iter+0x495/0x5e0 net/socket.c:1108<br /> call_write_iter include/linux/fs.h:2189 [inline]<br /> aio_write+0x63a/0x950 fs/aio.c:1600<br /> io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019<br /> __do_sys_io_submit fs/aio.c:2078 [inline]<br /> __se_sys_io_submit+0x293/0x770 fs/aio.c:2048<br /> __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> CPU: 1 PID: 5034 Comm: syz-executor350 Not tainted 6.2.0-rc6-syzkaller-80422-geda666ff2276 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023<br /> =====================================================<br /> <br /> We can follow the call chain and find that &amp;#39;bcm_tx_setup&amp;#39; function<br /> calls &amp;#39;memcpy_from_msg&amp;#39; to copy some content to the newly allocated<br /> frame of &amp;#39;op-&gt;frames&amp;#39;. After that the &amp;#39;len&amp;#39; field of copied structure<br /> being compared with some constant value (64 or 8). However, if<br /> &amp;#39;memcpy_from_msg&amp;#39; returns an error, we will compare some uninitialized<br /> memory. This triggers &amp;#39;uninit-value&amp;#39; issue.<br /> <br /> This patch will add &amp;#39;memcpy_from_msg&amp;#39; possible errors processing to<br /> avoid uninit-value issue.<br /> <br /> Tested via syzkaller

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix potential data race in rxrpc_wait_to_be_connected()<br /> <br /> Inside the loop in rxrpc_wait_to_be_connected() it checks call-&gt;error to<br /> see if it should exit the loop without first checking the call state. This<br /> is probably safe as if call-&gt;error is set, the call is dead anyway, but we<br /> should probably wait for the call state to have been set to completion<br /> first, lest it cause surprise on the way out.<br /> <br /> Fix this by only accessing call-&gt;error if the call is complete. We don&amp;#39;t<br /> actually need to access the error inside the loop as we&amp;#39;ll do that after.<br /> <br /> This caused the following report:<br /> <br /> BUG: KCSAN: data-race in rxrpc_send_data / rxrpc_set_call_completion<br /> <br /> write to 0xffff888159cf3c50 of 4 bytes by task 25673 on cpu 1:<br /> rxrpc_set_call_completion+0x71/0x1c0 net/rxrpc/call_state.c:22<br /> rxrpc_send_data_packet+0xba9/0x1650 net/rxrpc/output.c:479<br /> rxrpc_transmit_one+0x1e/0x130 net/rxrpc/output.c:714<br /> rxrpc_decant_prepared_tx net/rxrpc/call_event.c:326 [inline]<br /> rxrpc_transmit_some_data+0x496/0x600 net/rxrpc/call_event.c:350<br /> rxrpc_input_call_event+0x564/0x1220 net/rxrpc/call_event.c:464<br /> rxrpc_io_thread+0x307/0x1d80 net/rxrpc/io_thread.c:461<br /> kthread+0x1ac/0x1e0 kernel/kthread.c:376<br /> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308<br /> <br /> read to 0xffff888159cf3c50 of 4 bytes by task 25672 on cpu 0:<br /> rxrpc_send_data+0x29e/0x1950 net/rxrpc/sendmsg.c:296<br /> rxrpc_do_sendmsg+0xb7a/0xc20 net/rxrpc/sendmsg.c:726<br /> rxrpc_sendmsg+0x413/0x520 net/rxrpc/af_rxrpc.c:565<br /> sock_sendmsg_nosec net/socket.c:724 [inline]<br /> sock_sendmsg net/socket.c:747 [inline]<br /> ____sys_sendmsg+0x375/0x4c0 net/socket.c:2501<br /> ___sys_sendmsg net/socket.c:2555 [inline]<br /> __sys_sendmmsg+0x263/0x500 net/socket.c:2641<br /> __do_sys_sendmmsg net/socket.c:2670 [inline]<br /> __se_sys_sendmmsg net/socket.c:2667 [inline]<br /> __x64_sys_sendmmsg+0x57/0x60 net/socket.c:2667<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> value changed: 0x00000000 -&gt; 0xffffffea

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kernel/fail_function: fix memory leak with using debugfs_lookup()<br /> <br /> When calling debugfs_lookup() the result must have dput() called on it,<br /> otherwise the memory will leak over time. To make things simpler, just<br /> call debugfs_lookup_and_remove() instead which handles all of the logic<br /> at once.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Handle pairing of E-switch via uplink un/load APIs<br /> <br /> In case user switch a device from switchdev mode to legacy mode, mlx5<br /> first unpair the E-switch and afterwards unload the uplink vport.<br /> From the other hand, in case user remove or reload a device, mlx5<br /> first unload the uplink vport and afterwards unpair the E-switch.<br /> <br /> The latter is causing a bug[1], hence, handle pairing of E-switch as<br /> part of uplink un/load APIs.<br /> <br /> [1]<br /> In case VF_LAG is used, every tc fdb flow is duplicated to the peer<br /> esw. However, the original esw keeps a pointer to this duplicated<br /> flow, not the peer esw.<br /> e.g.: if user create tc fdb flow over esw0, the flow is duplicated<br /> over esw1, in FW/HW, but in SW, esw0 keeps a pointer to the duplicated<br /> flow.<br /> During module unload while a peer tc fdb flow is still offloaded, in<br /> case the first device to be removed is the peer device (esw1 in the<br /> example above), the peer net-dev is destroyed, and so the mlx5e_priv<br /> is memset to 0.<br /> Afterwards, the peer device is trying to unpair himself from the<br /> original device (esw0 in the example above). Unpair API invoke the<br /> original device to clear peer flow from its eswitch (esw0), but the<br /> peer flow, which is stored over the original eswitch (esw0), is<br /> trying to use the peer mlx5e_priv, which is memset to 0 and result in<br /> bellow kernel-oops.<br /> <br /> [ 157.964081 ] BUG: unable to handle page fault for address: 000000000002ce60<br /> [ 157.964662 ] #PF: supervisor read access in kernel mode<br /> [ 157.965123 ] #PF: error_code(0x0000) - not-present page<br /> [ 157.965582 ] PGD 0 P4D 0<br /> [ 157.965866 ] Oops: 0000 [#1] SMP<br /> [ 157.967670 ] RIP: 0010:mlx5e_tc_del_fdb_flow+0x48/0x460 [mlx5_core]<br /> [ 157.976164 ] Call Trace:<br /> [ 157.976437 ] <br /> [ 157.976690 ] __mlx5e_tc_del_fdb_peer_flow+0xe6/0x100 [mlx5_core]<br /> [ 157.977230 ] mlx5e_tc_clean_fdb_peer_flows+0x67/0x90 [mlx5_core]<br /> [ 157.977767 ] mlx5_esw_offloads_unpair+0x2d/0x1e0 [mlx5_core]<br /> [ 157.984653 ] mlx5_esw_offloads_devcom_event+0xbf/0x130 [mlx5_core]<br /> [ 157.985212 ] mlx5_devcom_send_event+0xa3/0xb0 [mlx5_core]<br /> [ 157.985714 ] esw_offloads_disable+0x5a/0x110 [mlx5_core]<br /> [ 157.986209 ] mlx5_eswitch_disable_locked+0x152/0x170 [mlx5_core]<br /> [ 157.986757 ] mlx5_eswitch_disable+0x51/0x80 [mlx5_core]<br /> [ 157.987248 ] mlx5_unload+0x2a/0xb0 [mlx5_core]<br /> [ 157.987678 ] mlx5_uninit_one+0x5f/0xd0 [mlx5_core]<br /> [ 157.988127 ] remove_one+0x64/0xe0 [mlx5_core]<br /> [ 157.988549 ] pci_device_remove+0x31/0xa0<br /> [ 157.988933 ] device_release_driver_internal+0x18f/0x1f0<br /> [ 157.989402 ] driver_detach+0x3f/0x80<br /> [ 157.989754 ] bus_remove_driver+0x70/0xf0<br /> [ 157.990129 ] pci_unregister_driver+0x34/0x90<br /> [ 157.990537 ] mlx5_cleanup+0xc/0x1c [mlx5_core]<br /> [ 157.990972 ] __x64_sys_delete_module+0x15a/0x250<br /> [ 157.991398 ] ? exit_to_user_mode_prepare+0xea/0x110<br /> [ 157.991840 ] do_syscall_64+0x3d/0x90<br /> [ 157.992198 ] entry_SYSCALL_64_after_hwframe+0x46/0xb0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix deadlock when aborting transaction during relocation with scrub<br /> <br /> Before relocating a block group we pause scrub, then do the relocation and<br /> then unpause scrub. The relocation process requires starting and committing<br /> a transaction, and if we have a failure in the critical section of the<br /> transaction commit path (transaction state &gt;= TRANS_STATE_COMMIT_START),<br /> we will deadlock if there is a paused scrub.<br /> <br /> That results in stack traces like the following:<br /> <br /> [42.479] BTRFS info (device sdc): relocating block group 53876686848 flags metadata|raid6<br /> [42.936] BTRFS warning (device sdc): Skipping commit of aborted transaction.<br /> [42.936] ------------[ cut here ]------------<br /> [42.936] BTRFS: Transaction aborted (error -28)<br /> [42.936] WARNING: CPU: 11 PID: 346822 at fs/btrfs/transaction.c:1977 btrfs_commit_transaction+0xcc8/0xeb0 [btrfs]<br /> [42.936] Modules linked in: dm_flakey dm_mod loop btrfs (...)<br /> [42.936] CPU: 11 PID: 346822 Comm: btrfs Tainted: G W 6.3.0-rc2-btrfs-next-127+ #1<br /> [42.936] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014<br /> [42.936] RIP: 0010:btrfs_commit_transaction+0xcc8/0xeb0 [btrfs]<br /> [42.936] Code: ff ff 45 8b (...)<br /> [42.936] RSP: 0018:ffffb58649633b48 EFLAGS: 00010282<br /> [42.936] RAX: 0000000000000000 RBX: ffff8be6ef4d5bd8 RCX: 0000000000000000<br /> [42.936] RDX: 0000000000000002 RSI: ffffffffb35e7782 RDI: 00000000ffffffff<br /> [42.936] RBP: ffff8be6ef4d5c98 R08: 0000000000000000 R09: ffffb586496339e8<br /> [42.936] R10: 0000000000000001 R11: 0000000000000001 R12: ffff8be6d38c7c00<br /> [42.936] R13: 00000000ffffffe4 R14: ffff8be6c268c000 R15: ffff8be6ef4d5cf0<br /> [42.936] FS: 00007f381a82b340(0000) GS:ffff8beddfcc0000(0000) knlGS:0000000000000000<br /> [42.936] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [42.936] CR2: 00007f1e35fb7638 CR3: 0000000117680006 CR4: 0000000000370ee0<br /> [42.936] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [42.936] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [42.936] Call Trace:<br /> [42.936] <br /> [42.936] ? start_transaction+0xcb/0x610 [btrfs]<br /> [42.936] prepare_to_relocate+0x111/0x1a0 [btrfs]<br /> [42.936] relocate_block_group+0x57/0x5d0 [btrfs]<br /> [42.936] ? btrfs_wait_nocow_writers+0x25/0xb0 [btrfs]<br /> [42.936] btrfs_relocate_block_group+0x248/0x3c0 [btrfs]<br /> [42.936] ? __pfx_autoremove_wake_function+0x10/0x10<br /> [42.936] btrfs_relocate_chunk+0x3b/0x150 [btrfs]<br /> [42.936] btrfs_balance+0x8ff/0x11d0 [btrfs]<br /> [42.936] ? __kmem_cache_alloc_node+0x14a/0x410<br /> [42.936] btrfs_ioctl+0x2334/0x32c0 [btrfs]<br /> [42.937] ? mod_objcg_state+0xd2/0x360<br /> [42.937] ? refill_obj_stock+0xb0/0x160<br /> [42.937] ? seq_release+0x25/0x30<br /> [42.937] ? __rseq_handle_notify_resume+0x3b5/0x4b0<br /> [42.937] ? percpu_counter_add_batch+0x2e/0xa0<br /> [42.937] ? __x64_sys_ioctl+0x88/0xc0<br /> [42.937] __x64_sys_ioctl+0x88/0xc0<br /> [42.937] do_syscall_64+0x38/0x90<br /> [42.937] entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> [42.937] RIP: 0033:0x7f381a6ffe9b<br /> [42.937] Code: 00 48 89 44 24 (...)<br /> [42.937] RSP: 002b:00007ffd45ecf060 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> [42.937] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f381a6ffe9b<br /> [42.937] RDX: 00007ffd45ecf150 RSI: 00000000c4009420 RDI: 0000000000000003<br /> [42.937] RBP: 0000000000000003 R08: 0000000000000013 R09: 0000000000000000<br /> [42.937] R10: 00007f381a60c878 R11: 0000000000000246 R12: 00007ffd45ed0423<br /> [42.937] R13: 00007ffd45ecf150 R14: 0000000000000000 R15: 00007ffd45ecf148<br /> [42.937] <br /> [42.937] ---[ end trace 0000000000000000 ]---<br /> [42.937] BTRFS: error (device sdc: state A) in cleanup_transaction:1977: errno=-28 No space left<br /> [59.196] INFO: task btrfs:346772 blocked for more than 120 seconds.<br /> [59.196] Tainted: G W 6.3.0-rc2-btrfs-next-127+ #1<br /> [59.196] "echo 0 &gt; /proc/sys/kernel/hung_<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: ov2740: Fix memleak in ov2740_init_controls()<br /> <br /> There is a kmemleak when testing the media/i2c/ov2740.c with bpf mock<br /> device:<br /> <br /> unreferenced object 0xffff8881090e19e0 (size 16):<br /> comm "51-i2c-ov2740", pid 278, jiffies 4294781584 (age 23.613s)<br /> hex dump (first 16 bytes):<br /> 00 f3 7c 0b 81 88 ff ff 80 75 6a 09 81 88 ff ff ..|......uj.....<br /> backtrace:<br /> [] __kmalloc_node+0x44/0x1b0<br /> [] kvmalloc_node+0x34/0x180<br /> [] v4l2_ctrl_handler_init_class+0x11d/0x180<br /> [videodev]<br /> [] ov2740_probe+0x37d/0x84f [ov2740]<br /> [] i2c_device_probe+0x28d/0x680<br /> [] really_probe+0x17c/0x3f0<br /> [] __driver_probe_device+0xe3/0x170<br /> [] device_driver_attach+0x34/0x80<br /> [] bind_store+0x10b/0x1a0<br /> [] drv_attr_store+0x49/0x70<br /> [] sysfs_kf_write+0x8c/0xb0<br /> [] kernfs_fop_write_iter+0x216/0x2e0<br /> [] vfs_write+0x658/0x810<br /> [] ksys_write+0xd6/0x1b0<br /> [] do_syscall_64+0x38/0x90<br /> [] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> ov2740_init_controls() won&amp;#39;t clean all the allocated resources in fail<br /> path, which may causes the memleaks. Add v4l2_ctrl_handler_free() to<br /> prevent memleak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/qaic: Fix slicing memory leak<br /> <br /> The temporary buffer storing slicing configuration data from user is only<br /> freed on error. This is a memory leak. Free the buffer unconditionally.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix BUG_ON condition in btrfs_cancel_balance<br /> <br /> Pausing and canceling balance can race to interrupt balance lead to BUG_ON<br /> panic in btrfs_cancel_balance. The BUG_ON condition in btrfs_cancel_balance<br /> does not take this race scenario into account.<br /> <br /> However, the race condition has no other side effects. We can fix that.<br /> <br /> Reproducing it with panic trace like this:<br /> <br /> kernel BUG at fs/btrfs/volumes.c:4618!<br /> RIP: 0010:btrfs_cancel_balance+0x5cf/0x6a0<br /> Call Trace:<br /> <br /> ? do_nanosleep+0x60/0x120<br /> ? hrtimer_nanosleep+0xb7/0x1a0<br /> ? sched_core_clone_cookie+0x70/0x70<br /> btrfs_ioctl_balance_ctl+0x55/0x70<br /> btrfs_ioctl+0xa46/0xd20<br /> __x64_sys_ioctl+0x7d/0xa0<br /> do_syscall_64+0x38/0x80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Race scenario as follows:<br /> &gt; mutex_unlock(&amp;fs_info-&gt;balance_mutex);<br /> &gt; --------------------<br /> &gt; .......issue pause and cancel req in another thread<br /> &gt; --------------------<br /> &gt; ret = __btrfs_balance(fs_info);<br /> &gt;<br /> &gt; mutex_lock(&amp;fs_info-&gt;balance_mutex);<br /> &gt; if (ret == -ECANCELED &amp;&amp; atomic_read(&amp;fs_info-&gt;balance_pause_req)) {<br /> &gt; btrfs_info(fs_info, "balance: paused");<br /> &gt; btrfs_exclop_balance(fs_info, BTRFS_EXCLOP_BALANCE_PAUSED);<br /> &gt; }