Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: copy last block omitted in ice_get_module_eeprom()<br /> <br /> ice_get_module_eeprom() is broken since commit e9c9692c8a81 ("ice:<br /> Reimplement module reads used by ethtool") In this refactor,<br /> ice_get_module_eeprom() reads the eeprom in blocks of size 8.<br /> But the condition that should protect the buffer overflow<br /> ignores the last block. The last block always contains zeros.<br /> <br /> Bug uncovered by ethtool upstream commit 9538f384b535<br /> ("netlink: eeprom: Defer page requests to individual parsers")<br /> After this commit, ethtool reads a block with length = 1;<br /> to read the SFF-8024 identifier value.<br /> <br /> unpatched driver:<br /> $ ethtool -m enp65s0f0np0 offset 0x90 length 8<br /> Offset Values<br /> ------ ------<br /> 0x0090: 00 00 00 00 00 00 00 00<br /> $ ethtool -m enp65s0f0np0 offset 0x90 length 12<br /> Offset Values<br /> ------ ------<br /> 0x0090: 00 00 01 a0 4d 65 6c 6c 00 00 00 00<br /> $<br /> <br /> $ ethtool -m enp65s0f0np0<br /> Offset Values<br /> ------ ------<br /> 0x0000: 11 06 06 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> 0x0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> 0x0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> 0x0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> 0x0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> 0x0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> 0x0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 01 08 00<br /> 0x0070: 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> <br /> patched driver:<br /> $ ethtool -m enp65s0f0np0 offset 0x90 length 8<br /> Offset Values<br /> ------ ------<br /> 0x0090: 00 00 01 a0 4d 65 6c 6c<br /> $ ethtool -m enp65s0f0np0 offset 0x90 length 12<br /> Offset Values<br /> ------ ------<br /> 0x0090: 00 00 01 a0 4d 65 6c 6c 61 6e 6f 78<br /> $ ethtool -m enp65s0f0np0<br /> Identifier : 0x11 (QSFP28)<br /> Extended identifier : 0x00<br /> Extended identifier description : 1.5W max. Power consumption<br /> Extended identifier description : No CDR in TX, No CDR in RX<br /> Extended identifier description : High Power Class (&gt; 3.5 W) not enabled<br /> Connector : 0x23 (No separable connector)<br /> Transceiver codes : 0x88 0x00 0x00 0x00 0x00 0x00 0x00 0x00<br /> Transceiver type : 40G Ethernet: 40G Base-CR4<br /> Transceiver type : 25G Ethernet: 25G Base-CR CA-N<br /> Encoding : 0x05 (64B/66B)<br /> BR, Nominal : 25500Mbps<br /> Rate identifier : 0x00<br /> Length (SMF,km) : 0km<br /> Length (OM3 50um) : 0m<br /> Length (OM2 50um) : 0m<br /> Length (OM1 62.5um) : 0m<br /> Length (Copper or Active cable) : 1m<br /> Transmitter technology : 0xa0 (Copper cable unequalized)<br /> Attenuation at 2.5GHz : 4db<br /> Attenuation at 5.0GHz : 5db<br /> Attenuation at 7.0GHz : 7db<br /> Attenuation at 12.9GHz : 10db<br /> ........<br /> ....

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ila: do not generate empty messages in ila_xlat_nl_cmd_get_mapping()<br /> <br /> ila_xlat_nl_cmd_get_mapping() generates an empty skb,<br /> triggerring a recent sanity check [1].<br /> <br /> Instead, return an error code, so that user space<br /> can get it.<br /> <br /> [1]<br /> skb_assert_len<br /> WARNING: CPU: 0 PID: 5923 at include/linux/skbuff.h:2527 skb_assert_len include/linux/skbuff.h:2527 [inline]<br /> WARNING: CPU: 0 PID: 5923 at include/linux/skbuff.h:2527 __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156<br /> Modules linked in:<br /> CPU: 0 PID: 5923 Comm: syz-executor269 Not tainted 6.2.0-syzkaller-18300-g2ebd1fbb946d #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/21/2023<br /> pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : skb_assert_len include/linux/skbuff.h:2527 [inline]<br /> pc : __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156<br /> lr : skb_assert_len include/linux/skbuff.h:2527 [inline]<br /> lr : __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156<br /> sp : ffff80001e0d6c40<br /> x29: ffff80001e0d6e60 x28: dfff800000000000 x27: ffff0000c86328c0<br /> x26: dfff800000000000 x25: ffff0000c8632990 x24: ffff0000c8632a00<br /> x23: 0000000000000000 x22: 1fffe000190c6542 x21: ffff0000c8632a10<br /> x20: ffff0000c8632a00 x19: ffff80001856e000 x18: ffff80001e0d5fc0<br /> x17: 0000000000000000 x16: ffff80001235d16c x15: 0000000000000000<br /> x14: 0000000000000000 x13: 0000000000000001 x12: 0000000000000001<br /> x11: ff80800008353a30 x10: 0000000000000000 x9 : 21567eaf25bfb600<br /> x8 : 21567eaf25bfb600 x7 : 0000000000000001 x6 : 0000000000000001<br /> x5 : ffff80001e0d6558 x4 : ffff800015c74760 x3 : ffff800008596744<br /> x2 : 0000000000000001 x1 : 0000000100000000 x0 : 000000000000000e<br /> Call trace:<br /> skb_assert_len include/linux/skbuff.h:2527 [inline]<br /> __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156<br /> dev_queue_xmit include/linux/netdevice.h:3033 [inline]<br /> __netlink_deliver_tap_skb net/netlink/af_netlink.c:307 [inline]<br /> __netlink_deliver_tap+0x45c/0x6f8 net/netlink/af_netlink.c:325<br /> netlink_deliver_tap+0xf4/0x174 net/netlink/af_netlink.c:338<br /> __netlink_sendskb net/netlink/af_netlink.c:1283 [inline]<br /> netlink_sendskb+0x6c/0x154 net/netlink/af_netlink.c:1292<br /> netlink_unicast+0x334/0x8d4 net/netlink/af_netlink.c:1380<br /> nlmsg_unicast include/net/netlink.h:1099 [inline]<br /> genlmsg_unicast include/net/genetlink.h:433 [inline]<br /> genlmsg_reply include/net/genetlink.h:443 [inline]<br /> ila_xlat_nl_cmd_get_mapping+0x620/0x7d0 net/ipv6/ila/ila_xlat.c:493<br /> genl_family_rcv_msg_doit net/netlink/genetlink.c:968 [inline]<br /> genl_family_rcv_msg net/netlink/genetlink.c:1048 [inline]<br /> genl_rcv_msg+0x938/0xc1c net/netlink/genetlink.c:1065<br /> netlink_rcv_skb+0x214/0x3c4 net/netlink/af_netlink.c:2574<br /> genl_rcv+0x38/0x50 net/netlink/genetlink.c:1076<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]<br /> netlink_unicast+0x660/0x8d4 net/netlink/af_netlink.c:1365<br /> netlink_sendmsg+0x800/0xae0 net/netlink/af_netlink.c:1942<br /> sock_sendmsg_nosec net/socket.c:714 [inline]<br /> sock_sendmsg net/socket.c:734 [inline]<br /> ____sys_sendmsg+0x558/0x844 net/socket.c:2479<br /> ___sys_sendmsg net/socket.c:2533 [inline]<br /> __sys_sendmsg+0x26c/0x33c net/socket.c:2562<br /> __do_sys_sendmsg net/socket.c:2571 [inline]<br /> __se_sys_sendmsg net/socket.c:2569 [inline]<br /> __arm64_sys_sendmsg+0x80/0x94 net/socket.c:2569<br /> __invoke_syscall arch/arm64/kernel/syscall.c:38 [inline]<br /> invoke_syscall+0x98/0x2c0 arch/arm64/kernel/syscall.c:52<br /> el0_svc_common+0x138/0x258 arch/arm64/kernel/syscall.c:142<br /> do_el0_svc+0x64/0x198 arch/arm64/kernel/syscall.c:193<br /> el0_svc+0x58/0x168 arch/arm64/kernel/entry-common.c:637<br /> el0t_64_sync_handler+0x84/0xf0 arch/arm64/kernel/entry-common.c:655<br /> el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:591<br /> irq event stamp: 136484<br /> hardirqs last enabled at (136483): [] __up_console_sem+0x60/0xb4 kernel/printk/printk.c:345<br /> hardirqs last disabled at (136484): [] el1_dbg+0x24/0x80 arch/arm64/kernel/entry-common.c:405<br /> softirqs last enabled at (136418): [] softirq_ha<br /> ---truncated---

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: core: Remove the /proc/scsi/${proc_name} directory earlier<br /> <br /> Remove the /proc/scsi/${proc_name} directory earlier to fix a race<br /> condition between unloading and reloading kernel modules. This fixes a bug<br /> introduced in 2009 by commit 77c019768f06 ("[SCSI] fix /proc memory leak in<br /> the SCSI core").<br /> <br /> Fix the following kernel warning:<br /> <br /> proc_dir_entry &amp;#39;scsi/scsi_debug&amp;#39; already registered<br /> WARNING: CPU: 19 PID: 27986 at fs/proc/generic.c:376 proc_register+0x27d/0x2e0<br /> Call Trace:<br /> proc_mkdir+0xb5/0xe0<br /> scsi_proc_hostdir_add+0xb5/0x170<br /> scsi_host_alloc+0x683/0x6c0<br /> sdebug_driver_probe+0x6b/0x2d0 [scsi_debug]<br /> really_probe+0x159/0x540<br /> __driver_probe_device+0xdc/0x230<br /> driver_probe_device+0x4f/0x120<br /> __device_attach_driver+0xef/0x180<br /> bus_for_each_drv+0xe5/0x130<br /> __device_attach+0x127/0x290<br /> device_initial_probe+0x17/0x20<br /> bus_probe_device+0x110/0x130<br /> device_add+0x673/0xc80<br /> device_register+0x1e/0x30<br /> sdebug_add_host_helper+0x1a7/0x3b0 [scsi_debug]<br /> scsi_debug_init+0x64f/0x1000 [scsi_debug]<br /> do_one_initcall+0xd7/0x470<br /> do_init_module+0xe7/0x330<br /> load_module+0x122a/0x12c0<br /> __do_sys_finit_module+0x124/0x1a0<br /> __x64_sys_finit_module+0x46/0x50<br /> do_syscall_64+0x38/0x80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: fdp: add null check of devm_kmalloc_array in fdp_nci_i2c_read_device_properties<br /> <br /> devm_kmalloc_array may fails, *fw_vsc_cfg might be null and cause<br /> out-of-bounds write in device_property_read_u8_array later.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: caif: Fix use-after-free in cfusbl_device_notify()<br /> <br /> syzbot reported use-after-free in cfusbl_device_notify() [1]. This<br /> causes a stack trace like below:<br /> <br /> BUG: KASAN: use-after-free in cfusbl_device_notify+0x7c9/0x870 net/caif/caif_usb.c:138<br /> Read of size 8 at addr ffff88807ac4e6f0 by task kworker/u4:6/1214<br /> <br /> CPU: 0 PID: 1214 Comm: kworker/u4:6 Not tainted 5.19.0-rc3-syzkaller-00146-g92f20ff72066 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> Workqueue: netns cleanup_net<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106<br /> print_address_description.constprop.0.cold+0xeb/0x467 mm/kasan/report.c:313<br /> print_report mm/kasan/report.c:429 [inline]<br /> kasan_report.cold+0xf4/0x1c6 mm/kasan/report.c:491<br /> cfusbl_device_notify+0x7c9/0x870 net/caif/caif_usb.c:138<br /> notifier_call_chain+0xb5/0x200 kernel/notifier.c:87<br /> call_netdevice_notifiers_info+0xb5/0x130 net/core/dev.c:1945<br /> call_netdevice_notifiers_extack net/core/dev.c:1983 [inline]<br /> call_netdevice_notifiers net/core/dev.c:1997 [inline]<br /> netdev_wait_allrefs_any net/core/dev.c:10227 [inline]<br /> netdev_run_todo+0xbc0/0x10f0 net/core/dev.c:10341<br /> default_device_exit_batch+0x44e/0x590 net/core/dev.c:11334<br /> ops_exit_list+0x125/0x170 net/core/net_namespace.c:167<br /> cleanup_net+0x4ea/0xb00 net/core/net_namespace.c:594<br /> process_one_work+0x996/0x1610 kernel/workqueue.c:2289<br /> worker_thread+0x665/0x1080 kernel/workqueue.c:2436<br /> kthread+0x2e9/0x3a0 kernel/kthread.c:376<br /> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302<br /> <br /> <br /> When unregistering a net device, unregister_netdevice_many_notify()<br /> sets the device&amp;#39;s reg_state to NETREG_UNREGISTERING, calls notifiers<br /> with NETDEV_UNREGISTER, and adds the device to the todo list.<br /> <br /> Later on, devices in the todo list are processed by netdev_run_todo().<br /> netdev_run_todo() waits devices&amp;#39; reference count become 1 while<br /> rebdoadcasting NETDEV_UNREGISTER notification.<br /> <br /> When cfusbl_device_notify() is called with NETDEV_UNREGISTER multiple<br /> times, the parent device might be freed. This could cause UAF.<br /> Processing NETDEV_UNREGISTER multiple times also causes inbalance of<br /> reference count for the module.<br /> <br /> This patch fixes the issue by accepting only first NETDEV_UNREGISTER<br /> notification.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> af_unix: fix struct pid leaks in OOB support<br /> <br /> syzbot reported struct pid leak [1].<br /> <br /> Issue is that queue_oob() calls maybe_add_creds() which potentially<br /> holds a reference on a pid.<br /> <br /> But skb-&gt;destructor is not set (either directly or by calling<br /> unix_scm_to_skb())<br /> <br /> This means that subsequent kfree_skb() or consume_skb() would leak<br /> this reference.<br /> <br /> In this fix, I chose to fully support scm even for the OOB message.<br /> <br /> [1]<br /> BUG: memory leak<br /> unreferenced object 0xffff8881053e7f80 (size 128):<br /> comm "syz-executor242", pid 5066, jiffies 4294946079 (age 13.220s)<br /> hex dump (first 32 bytes):<br /> 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] alloc_pid+0x6a/0x560 kernel/pid.c:180<br /> [] copy_process+0x169f/0x26c0 kernel/fork.c:2285<br /> [] kernel_clone+0xf7/0x610 kernel/fork.c:2684<br /> [] __do_sys_clone+0x7c/0xb0 kernel/fork.c:2825<br /> [] do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> [] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80<br /> [] entry_SYSCALL_64_after_hwframe+0x63/0xcd

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.