Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: Use READ_ONCE_NOCHECK in imprecise unwinding stack mode<br /> <br /> When CONFIG_FRAME_POINTER is unset, the stack unwinding function<br /> walk_stackframe randomly reads the stack and then, when KASAN is enabled,<br /> it can lead to the following backtrace:<br /> <br /> [ 0.000000] ==================================================================<br /> [ 0.000000] BUG: KASAN: stack-out-of-bounds in walk_stackframe+0xa6/0x11a<br /> [ 0.000000] Read of size 8 at addr ffffffff81807c40 by task swapper/0<br /> [ 0.000000]<br /> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.2.0-12919-g24203e6db61f #43<br /> [ 0.000000] Hardware name: riscv-virtio,qemu (DT)<br /> [ 0.000000] Call Trace:<br /> [ 0.000000] [] walk_stackframe+0x0/0x11a<br /> [ 0.000000] [] init_param_lock+0x26/0x2a<br /> [ 0.000000] [] walk_stackframe+0xa2/0x11a<br /> [ 0.000000] [] dump_stack_lvl+0x22/0x36<br /> [ 0.000000] [] print_report+0x198/0x4a8<br /> [ 0.000000] [] init_param_lock+0x26/0x2a<br /> [ 0.000000] [] walk_stackframe+0xa2/0x11a<br /> [ 0.000000] [] kasan_report+0x9a/0xc8<br /> [ 0.000000] [] walk_stackframe+0xa2/0x11a<br /> [ 0.000000] [] walk_stackframe+0xa2/0x11a<br /> [ 0.000000] [] desc_make_final+0x80/0x84<br /> [ 0.000000] [] stack_trace_save+0x88/0xa6<br /> [ 0.000000] [] filter_irq_stacks+0x72/0x76<br /> [ 0.000000] [] devkmsg_read+0x32a/0x32e<br /> [ 0.000000] [] kasan_save_stack+0x28/0x52<br /> [ 0.000000] [] desc_make_final+0x7c/0x84<br /> [ 0.000000] [] stack_trace_save+0x84/0xa6<br /> [ 0.000000] [] kasan_set_track+0x12/0x20<br /> [ 0.000000] [] __kasan_slab_alloc+0x58/0x5e<br /> [ 0.000000] [] __kmem_cache_create+0x21e/0x39a<br /> [ 0.000000] [] create_boot_cache+0x70/0x9c<br /> [ 0.000000] [] kmem_cache_init+0x6c/0x11e<br /> [ 0.000000] [] mm_init+0xd8/0xfe<br /> [ 0.000000] [] start_kernel+0x190/0x3ca<br /> [ 0.000000]<br /> [ 0.000000] The buggy address belongs to stack of task swapper/0<br /> [ 0.000000] and is located at offset 0 in frame:<br /> [ 0.000000] stack_trace_save+0x0/0xa6<br /> [ 0.000000]<br /> [ 0.000000] This frame has 1 object:<br /> [ 0.000000] [32, 56) &amp;#39;c&amp;#39;<br /> [ 0.000000]<br /> [ 0.000000] The buggy address belongs to the physical page:<br /> [ 0.000000] page:(____ptrval____) refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x81a07<br /> [ 0.000000] flags: 0x1000(reserved|zone=0)<br /> [ 0.000000] raw: 0000000000001000 ff600003f1e3d150 ff600003f1e3d150 0000000000000000<br /> [ 0.000000] raw: 0000000000000000 0000000000000000 00000001ffffffff<br /> [ 0.000000] page dumped because: kasan: bad access detected<br /> [ 0.000000]<br /> [ 0.000000] Memory state around the buggy address:<br /> [ 0.000000] ffffffff81807b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> [ 0.000000] ffffffff81807b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> [ 0.000000] &gt;ffffffff81807c00: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 f3<br /> [ 0.000000] ^<br /> [ 0.000000] ffffffff81807c80: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00<br /> [ 0.000000] ffffffff81807d00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> [ 0.000000] ==================================================================<br /> <br /> Fix that by using READ_ONCE_NOCHECK when reading the stack in imprecise<br /> mode.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bnxt_en: Avoid order-5 memory allocation for TPA data<br /> <br /> The driver needs to keep track of all the possible concurrent TPA (GRO/LRO)<br /> completions on the aggregation ring. On P5 chips, the maximum number<br /> of concurrent TPA is 256 and the amount of memory we allocate is order-5<br /> on systems using 4K pages. Memory allocation failure has been reported:<br /> <br /> NetworkManager: page allocation failure: order:5, mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), nodemask=(null),cpuset=/,mems_allowed=0-1<br /> CPU: 15 PID: 2995 Comm: NetworkManager Kdump: loaded Not tainted 5.10.156 #1<br /> Hardware name: Dell Inc. PowerEdge R660/0M1CC5, BIOS 0.2.25 08/12/2022<br /> Call Trace:<br /> dump_stack+0x57/0x6e<br /> warn_alloc.cold.120+0x7b/0xdd<br /> ? _cond_resched+0x15/0x30<br /> ? __alloc_pages_direct_compact+0x15f/0x170<br /> __alloc_pages_slowpath.constprop.108+0xc58/0xc70<br /> __alloc_pages_nodemask+0x2d0/0x300<br /> kmalloc_order+0x24/0xe0<br /> kmalloc_order_trace+0x19/0x80<br /> bnxt_alloc_mem+0x1150/0x15c0 [bnxt_en]<br /> ? bnxt_get_func_stat_ctxs+0x13/0x60 [bnxt_en]<br /> __bnxt_open_nic+0x12e/0x780 [bnxt_en]<br /> bnxt_open+0x10b/0x240 [bnxt_en]<br /> __dev_open+0xe9/0x180<br /> __dev_change_flags+0x1af/0x220<br /> dev_change_flags+0x21/0x60<br /> do_setlink+0x35c/0x1100<br /> <br /> Instead of allocating this big chunk of memory and dividing it up for the<br /> concurrent TPA instances, allocate each small chunk separately for each<br /> TPA instance. This will reduce it to order-0 allocations.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, sockmap: Fix an infinite loop error when len is 0 in tcp_bpf_recvmsg_parser()<br /> <br /> When the buffer length of the recvmsg system call is 0, we got the<br /> flollowing soft lockup problem:<br /> <br /> watchdog: BUG: soft lockup - CPU#3 stuck for 27s! [a.out:6149]<br /> CPU: 3 PID: 6149 Comm: a.out Kdump: loaded Not tainted 6.2.0+ #30<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014<br /> RIP: 0010:remove_wait_queue+0xb/0xc0<br /> Code: 5e 41 5f c3 cc cc cc cc 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 57 56 41 55 41 54 55 48 89 fd 53 48 89 f3 4c 8d 6b 18 4c 8d 73 20<br /> RSP: 0018:ffff88811b5978b8 EFLAGS: 00000246<br /> RAX: 0000000000000000 RBX: ffff88811a7d3780 RCX: ffffffffb7a4d768<br /> RDX: dffffc0000000000 RSI: ffff88811b597908 RDI: ffff888115408040<br /> RBP: 1ffff110236b2f1b R08: 0000000000000000 R09: ffff88811a7d37e7<br /> R10: ffffed10234fa6fc R11: 0000000000000001 R12: ffff88811179b800<br /> R13: 0000000000000001 R14: ffff88811a7d38a8 R15: ffff88811a7d37e0<br /> FS: 00007f6fb5398740(0000) GS:ffff888237180000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000020000000 CR3: 000000010b6ba002 CR4: 0000000000370ee0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> tcp_msg_wait_data+0x279/0x2f0<br /> tcp_bpf_recvmsg_parser+0x3c6/0x490<br /> inet_recvmsg+0x280/0x290<br /> sock_recvmsg+0xfc/0x120<br /> ____sys_recvmsg+0x160/0x3d0<br /> ___sys_recvmsg+0xf0/0x180<br /> __sys_recvmsg+0xea/0x1a0<br /> do_syscall_64+0x3f/0x90<br /> entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> <br /> The logic in tcp_bpf_recvmsg_parser is as follows:<br /> <br /> msg_bytes_ready:<br /> copied = sk_msg_recvmsg(sk, psock, msg, len, flags);<br /> if (!copied) {<br /> wait data;<br /> goto msg_bytes_ready;<br /> }<br /> <br /> In this case, "copied" always is 0, the infinite loop occurs.<br /> <br /> According to the Linux system call man page, 0 should be returned in this<br /> case. Therefore, in tcp_bpf_recvmsg_parser(), if the length is 0, directly<br /> return. Also modify several other functions with the same problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: mpi3mr: Fix mpi3mr_hba_port memory leak in mpi3mr_remove()<br /> <br /> Free mpi3mr_hba_port at .remove.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> SUNRPC: Fix a server shutdown leak<br /> <br /> Fix a race where kthread_stop() may prevent the threadfn from ever getting<br /> called. If that happens the svc_rqst will not be cleaned up.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: mpi3mr: Fix throttle_groups memory leak<br /> <br /> Add a missing kfree().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: mpi3mr: Fix expander node leak in mpi3mr_remove()<br /> <br /> Add a missing resource clean up in .remove.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: mpi3mr: Fix sas_hba.phy memory leak in mpi3mr_remove()<br /> <br /> Free mrioc-&gt;sas_hba.phy at .remove.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: smsc75xx: Limit packet length to skb-&gt;len<br /> <br /> Packet length retrieved from skb data may be larger than<br /> the actual socket buffer length (up to 9026 bytes). In such<br /> case the cloned skb passed up the network stack will leak<br /> kernel memory contents.