{"schema_version":"1.7.2","id":"OESA-2024-1566","modified":"2024-05-11T11:07:58Z","published":"2024-05-11T11:07:58Z","upstream":["CVE-2021-47182","CVE-2021-47199","CVE-2021-47211","CVE-2023-52609","CVE-2023-52610","CVE-2023-52616","CVE-2023-52618","CVE-2024-26635","CVE-2024-26636","CVE-2024-26640","CVE-2024-26641","CVE-2024-26752","CVE-2024-26766"],"summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: core: Fix scsi_mode_sense() buffer length handling\r\n\r\nSeveral problems exist with scsi_mode_sense() buffer length handling:\r\n\r\n 1) The allocation length field of the MODE SENSE(10) command is 16-bits,\n    occupying bytes 7 and 8 of the CDB. With this command, access to mode\n    pages larger than 255 bytes is thus possible. However, the CDB\n    allocation length field is set by assigning len to byte 8 only, thus\n    truncating buffer length larger than 255.\r\n\r\n 2) If scsi_mode_sense() is called with len smaller than 8 with\n    sdev-\u0026gt;use_10_for_ms set, or smaller than 4 otherwise, the buffer length\n    is increased to 8 and 4 respectively, and the buffer is zero filled\n    with these increased values, thus corrupting the memory following the\n    buffer.\r\n\r\nFix these 2 problems by using put_unaligned_be16() to set the allocation\nlength field of MODE SENSE(10) CDB and by returning an error when len is\ntoo small.\r\n\r\nFurthermore, if len is larger than 255B, always try MODE SENSE(10) first,\neven if the device driver did not set sdev-\u0026gt;use_10_for_ms. In case of\ninvalid opcode error for MODE SENSE(10), access to mode pages larger than\n255 bytes are not retried using MODE SENSE(6). To avoid buffer length\noverflows for the MODE_SENSE(10) case, check that len is smaller than 65535\nbytes.\r\n\r\nWhile at it, also fix the folowing:\r\n\r\n * Use get_unaligned_be16() to retrieve the mode data length and block\n   descriptor length fields of the mode sense reply header instead of using\n   an open coded calculation.\r\n\r\n * Fix the kdoc dbd argument explanation: the DBD bit stands for Disable\n   Block Descriptor, which is the opposite of what the dbd argument\n   description was.(CVE-2021-47182)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5e: CT, Fix multiple allocations and memleak of mod acts\r\n\r\nCT clear action offload adds additional mod hdr actions to the\nflow\u0026apos;s original mod actions in order to clear the registers which\nhold ct_state.\nWhen such flow also includes encap action, a neigh update event\ncan cause the driver to unoffload the flow and then reoffload it.\r\n\r\nEach time this happens, the ct clear handling adds that same set\nof mod hdr actions to reset ct_state until the max of mod hdr\nactions is reached.\r\n\r\nAlso the driver never releases the allocated mod hdr actions and\ncausing a memleak.\r\n\r\nFix above two issues by moving CT clear mod acts allocation\ninto the parsing actions phase and only use it when offloading the rule.\nThe release of mod acts will be done in the normal flow_put().\r\n\r\n backtrace:\n    [\u0026lt;000000007316e2f3\u0026gt;] krealloc+0x83/0xd0\n    [\u0026lt;00000000ef157de1\u0026gt;] mlx5e_mod_hdr_alloc+0x147/0x300 [mlx5_core]\n    [\u0026lt;00000000970ce4ae\u0026gt;] mlx5e_tc_match_to_reg_set_and_get_id+0xd7/0x240 [mlx5_core]\n    [\u0026lt;0000000067c5fa17\u0026gt;] mlx5e_tc_match_to_reg_set+0xa/0x20 [mlx5_core]\n    [\u0026lt;00000000d032eb98\u0026gt;] mlx5_tc_ct_entry_set_registers.isra.0+0x36/0xc0 [mlx5_core]\n    [\u0026lt;00000000fd23b869\u0026gt;] mlx5_tc_ct_flow_offload+0x272/0x1f10 [mlx5_core]\n    [\u0026lt;000000004fc24acc\u0026gt;] mlx5e_tc_offload_fdb_rules.part.0+0x150/0x620 [mlx5_core]\n    [\u0026lt;00000000dc741c17\u0026gt;] mlx5e_tc_encap_flows_add+0x489/0x690 [mlx5_core]\n    [\u0026lt;00000000e92e49d7\u0026gt;] mlx5e_rep_update_flows+0x6e4/0x9b0 [mlx5_core]\n    [\u0026lt;00000000f60f5602\u0026gt;] mlx5e_rep_neigh_update+0x39a/0x5d0 [mlx5_core](CVE-2021-47199)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: usb-audio: fix null pointer dereference on pointer cs_desc\r\n\r\nThe pointer cs_desc return from snd_usb_find_clock_source could\nbe null, so there is a potential null pointer dereference issue.\nFix this by adding a null check before dereference.(CVE-2021-47211)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbinder: fix race between mmput() and do_exit()\r\n\r\nTask A calls binder_update_page_range() to allocate and insert pages on\na remote address space from Task B. For this, Task A pins the remote mm\nvia mmget_not_zero() first. This can race with Task B do_exit() and the\nfinal mmput() refcount decrement will come from Task A.\r\n\r\n  Task A            | Task B\n  ------------------+------------------\n  mmget_not_zero()  |\n                    |  do_exit()\n                    |    exit_mm()\n                    |      mmput()\n  mmput()           |\n    exit_mmap()     |\n      remove_vma()  |\n        fput()      |\r\n\r\nIn this case, the work of ____fput() from Task B is queued up in Task A\nas TWA_RESUME. So in theory, Task A returns to userspace and the cleanup\nwork gets executed. However, Task A instead sleep, waiting for a reply\nfrom Task B that never comes (it\u0026apos;s dead).\r\n\r\nThis means the binder_deferred_release() is blocked until an unrelated\nbinder event forces Task A to go back to userspace. All the associated\ndeath notifications will also be delayed until then.\r\n\r\nIn order to fix this use mmput_async() that will schedule the work in\nthe corresponding mm-\u0026gt;async_put_work WQ instead of Task A.(CVE-2023-52609)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/sched: act_ct: fix skb leak and crash on ooo frags\r\n\r\nact_ct adds skb-\u0026gt;users before defragmentation. If frags arrive in order,\nthe last frag\u0026apos;s reference is reset in:\r\n\r\n  inet_frag_reasm_prepare\n    skb_morph\r\n\r\nwhich is not straightforward.\r\n\r\nHowever when frags arrive out of order, nobody unref the last frag, and\nall frags are leaked. The situation is even worse, as initiating packet\ncapture can lead to a crash[0] when skb has been cloned and shared at the\nsame time.\r\n\r\nFix the issue by removing skb_get() before defragmentation. act_ct\nreturns TC_ACT_CONSUMED when defrag failed or in progress.\r\n\r\n[0]:\n[  843.804823] ------------[ cut here ]------------\n[  843.809659] kernel BUG at net/core/skbuff.c:2091!\n[  843.814516] invalid opcode: 0000 [#1] PREEMPT SMP\n[  843.819296] CPU: 7 PID: 0 Comm: swapper/7 Kdump: loaded Tainted: G S 6.7.0-rc3 #2\n[  843.824107] Hardware name: XFUSION 1288H V6/BC13MBSBD, BIOS 1.29 11/25/2022\n[  843.828953] RIP: 0010:pskb_expand_head+0x2ac/0x300\n[  843.833805] Code: 8b 70 28 48 85 f6 74 82 48 83 c6 08 bf 01 00 00 00 e8 38 bd ff ff 8b 83 c0 00 00 00 48 03 83 c8 00 00 00 e9 62 ff ff ff 0f 0b \u0026lt;0f\u0026gt; 0b e8 8d d0 ff ff e9 b3 fd ff ff 81 7c 24 14 40 01 00 00 4c 89\n[  843.843698] RSP: 0018:ffffc9000cce07c0 EFLAGS: 00010202\n[  843.848524] RAX: 0000000000000002 RBX: ffff88811a211d00 RCX: 0000000000000820\n[  843.853299] RDX: 0000000000000640 RSI: 0000000000000000 RDI: ffff88811a211d00\n[  843.857974] RBP: ffff888127d39518 R08: 00000000bee97314 R09: 0000000000000000\n[  843.862584] R10: 0000000000000000 R11: ffff8881109f0000 R12: 0000000000000880\n[  843.867147] R13: ffff888127d39580 R14: 0000000000000640 R15: ffff888170f7b900\n[  843.871680] FS:  0000000000000000(0000) GS:ffff889ffffc0000(0000) knlGS:0000000000000000\n[  843.876242] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  843.880778] CR2: 00007fa42affcfb8 CR3: 000000011433a002 CR4: 0000000000770ef0\n[  843.885336] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[  843.889809] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[  843.894229] PKRU: 55555554\n[  843.898539] Call Trace:\n[  843.902772]  \u0026lt;IRQ\u0026gt;\n[  843.906922]  ? __die_body+0x1e/0x60\n[  843.911032]  ? die+0x3c/0x60\n[  843.915037]  ? do_trap+0xe2/0x110\n[  843.918911]  ? pskb_expand_head+0x2ac/0x300\n[  843.922687]  ? do_error_trap+0x65/0x80\n[  843.926342]  ? pskb_expand_head+0x2ac/0x300\n[  843.929905]  ? exc_invalid_op+0x50/0x60\n[  843.933398]  ? pskb_expand_head+0x2ac/0x300\n[  843.936835]  ? asm_exc_invalid_op+0x1a/0x20\n[  843.940226]  ? pskb_expand_head+0x2ac/0x300\n[  843.943580]  inet_frag_reasm_prepare+0xd1/0x240\n[  843.946904]  ip_defrag+0x5d4/0x870\n[  843.950132]  nf_ct_handle_fragments+0xec/0x130 [nf_conntrack]\n[  843.953334]  tcf_ct_act+0x252/0xd90 [act_ct]\n[  843.956473]  ? tcf_mirred_act+0x516/0x5a0 [act_mirred]\n[  843.959657]  tcf_action_exec+0xa1/0x160\n[  843.962823]  fl_classify+0x1db/0x1f0 [cls_flower]\n[  843.966010]  ? skb_clone+0x53/0xc0\n[  843.969173]  tcf_classify+0x24d/0x420\n[  843.972333]  tc_run+0x8f/0xf0\n[  843.975465]  __netif_receive_skb_core+0x67a/0x1080\n[  843.978634]  ? dev_gro_receive+0x249/0x730\n[  843.981759]  __netif_receive_skb_list_core+0x12d/0x260\n[  843.984869]  netif_receive_skb_list_internal+0x1cb/0x2f0\n[  843.987957]  ? mlx5e_handle_rx_cqe_mpwrq_rep+0xfa/0x1a0 [mlx5_core]\n[  843.991170]  napi_complete_done+0x72/0x1a0\n[  843.994305]  mlx5e_napi_poll+0x28c/0x6d0 [mlx5_core]\n[  843.997501]  __napi_poll+0x25/0x1b0\n[  844.000627]  net_rx_action+0x256/0x330\n[  844.003705]  __do_softirq+0xb3/0x29b\n[  844.006718]  irq_exit_rcu+0x9e/0xc0\n[  844.009672]  common_interrupt+0x86/0xa0\n[  844.012537]  \u0026lt;/IRQ\u0026gt;\n[  844.015285]  \u0026lt;TASK\u0026gt;\n[  844.017937]  asm_common_interrupt+0x26/0x40\n[  844.020591] RIP: 0010:acpi_safe_halt+0x1b/0x20\n[  844.023247] Code: ff 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 65 48 8b 04 25 00 18 03 00 48 8b 00 a8 08 75 0c 66 90 0f 00 2d 81 d0 44 00 fb\n---truncated---(CVE-2023-52610)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncrypto: lib/mpi - Fix unexpected pointer access in mpi_ec_init\r\n\r\nWhen the mpi_ec_ctx structure is initialized, some fields are not\ncleared, causing a crash when referencing the field when the\nstructure was released. Initially, this issue was ignored because\nmemory for mpi_ec_ctx is allocated with the __GFP_ZERO flag.\nFor example, this error will be triggered when calculating the\nZa value for SM2 separately.(CVE-2023-52616)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nblock/rnbd-srv: Check for unlikely string overflow\r\n\r\nSince \u0026quot;dev_search_path\u0026quot; can technically be as large as PATH_MAX,\nthere was a risk of truncation when copying it and a second string\ninto \u0026quot;full_path\u0026quot; since it was also PATH_MAX sized. The W=1 builds were\nreporting this warning:\r\n\r\ndrivers/block/rnbd/rnbd-srv.c: In function \u0026apos;process_msg_open.isra\u0026apos;:\ndrivers/block/rnbd/rnbd-srv.c:616:51: warning: \u0026apos;%s\u0026apos; directive output may be truncated writing up to 254 bytes into a region of size between 0 and 4095 [-Wformat-truncation=]\n  616 |                 snprintf(full_path, PATH_MAX, \u0026quot;%s/%s\u0026quot;,\n      |                                                   ^~\nIn function \u0026apos;rnbd_srv_get_full_path\u0026apos;,\n    inlined from \u0026apos;process_msg_open.isra\u0026apos; at drivers/block/rnbd/rnbd-srv.c:721:14: drivers/block/rnbd/rnbd-srv.c:616:17: note: \u0026apos;snprintf\u0026apos; output between 2 and 4351 bytes into a destination of size 4096\n  616 |                 snprintf(full_path, PATH_MAX, \u0026quot;%s/%s\u0026quot;,\n      |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n  617 |                          dev_search_path, dev_name);\n      |                          ~~~~~~~~~~~~~~~~~~~~~~~~~~\r\n\r\nTo fix this, unconditionally check for truncation (as was already done\nfor the case where \u0026quot;%SESSNAME%\u0026quot; was present).(CVE-2023-52618)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nllc: Drop support for ETH_P_TR_802_2.\r\n\r\nsyzbot reported an uninit-value bug below. [0]\r\n\r\nllc supports ETH_P_802_2 (0x0004) and used to support ETH_P_TR_802_2\n(0x0011), and syzbot abused the latter to trigger the bug.\r\n\r\n  write$tun(r0, \u0026amp;(0x7f0000000040)={@val={0x0, 0x11}, @val, @mpls={[], @llc={@snap={0xaa, 0x1, \u0026apos;)\u0026apos;, \u0026quot;90e5dd\u0026quot;}}}}, 0x16)\r\n\r\nllc_conn_handler() initialises local variables {saddr,daddr}.mac\nbased on skb in llc_pdu_decode_sa()/llc_pdu_decode_da() and passes\nthem to __llc_lookup().\r\n\r\nHowever, the initialisation is done only when skb-\u0026gt;protocol is\nhtons(ETH_P_802_2), otherwise, __llc_lookup_established() and\n__llc_lookup_listener() will read garbage.\r\n\r\nThe missing initialisation existed prior to commit 211ed865108e\n(\u0026quot;net: delete all instances of special processing for token ring\u0026quot;).\r\n\r\nIt removed the part to kick out the token ring stuff but forgot to\nclose the door allowing ETH_P_TR_802_2 packets to sneak into llc_rcv().\r\n\r\nLet\u0026apos;s remove llc_tr_packet_type and complete the deprecation.\r\n\r\n[0]:\nBUG: KMSAN: uninit-value in __llc_lookup_established+0xe9d/0xf90\n __llc_lookup_established+0xe9d/0xf90\n __llc_lookup net/llc/llc_conn.c:611 [inline]\n llc_conn_handler+0x4bd/0x1360 net/llc/llc_conn.c:791\n llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206\n __netif_receive_skb_one_core net/core/dev.c:5527 [inline]\n __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5641\n netif_receive_skb_internal net/core/dev.c:5727 [inline]\n netif_receive_skb+0x58/0x660 net/core/dev.c:5786\n tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555\n tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002\n tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048\n call_write_iter include/linux/fs.h:2020 [inline]\n new_sync_write fs/read_write.c:491 [inline]\n vfs_write+0x8ef/0x1490 fs/read_write.c:584\n ksys_write+0x20f/0x4c0 fs/read_write.c:637\n __do_sys_write fs/read_write.c:649 [inline]\n __se_sys_write fs/read_write.c:646 [inline]\n __x64_sys_write+0x93/0xd0 fs/read_write.c:646\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x44/0x110 arch/x86/entry/common.c:82\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nLocal variable daddr created at:\n llc_conn_handler+0x53/0x1360 net/llc/llc_conn.c:783\n llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206\r\n\r\nCPU: 1 PID: 5004 Comm: syz-executor994 Not tainted 6.6.0-syzkaller-14500-g1c41041124bd #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023(CVE-2024-26635)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nllc: make llc_ui_sendmsg() more robust against bonding changes\r\n\r\nsyzbot was able to trick llc_ui_sendmsg(), allocating an skb with no\nheadroom, but subsequently trying to push 14 bytes of Ethernet header [1]\r\n\r\nLike some others, llc_ui_sendmsg() releases the socket lock before\ncalling sock_alloc_send_skb().\nThen it acquires it again, but does not redo all the sanity checks\nthat were performed.\r\n\r\nThis fix:\r\n\r\n- Uses LL_RESERVED_SPACE() to reserve space.\n- Check all conditions again after socket lock is held again.\n- Do not account Ethernet header for mtu limitation.\r\n\r\n[1]\r\n\r\nskbuff: skb_under_panic: text:ffff800088baa334 len:1514 put:14 head:ffff0000c9c37000 data:ffff0000c9c36ff2 tail:0x5dc end:0x6c0 dev:bond0\r\n\r\n kernel BUG at net/core/skbuff.c:193 !\nInternal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP\nModules linked in:\nCPU: 0 PID: 6875 Comm: syz-executor.0 Not tainted 6.7.0-rc8-syzkaller-00101-g0802e17d9aca-dirty #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023\npstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : skb_panic net/core/skbuff.c:189 [inline]\n pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203\n lr : skb_panic net/core/skbuff.c:189 [inline]\n lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203\nsp : ffff800096f97000\nx29: ffff800096f97010 x28: ffff80008cc8d668 x27: dfff800000000000\nx26: ffff0000cb970c90 x25: 00000000000005dc x24: ffff0000c9c36ff2\nx23: ffff0000c9c37000 x22: 00000000000005ea x21: 00000000000006c0\nx20: 000000000000000e x19: ffff800088baa334 x18: 1fffe000368261ce\nx17: ffff80008e4ed000 x16: ffff80008a8310f8 x15: 0000000000000001\nx14: 1ffff00012df2d58 x13: 0000000000000000 x12: 0000000000000000\nx11: 0000000000000001 x10: 0000000000ff0100 x9 : e28a51f1087e8400\nx8 : e28a51f1087e8400 x7 : ffff80008028f8d0 x6 : 0000000000000000\nx5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff800082b78714\nx2 : 0000000000000001 x1 : 0000000100000000 x0 : 0000000000000089\nCall trace:\n  skb_panic net/core/skbuff.c:189 [inline]\n  skb_under_panic+0x13c/0x140 net/core/skbuff.c:203\n  skb_push+0xf0/0x108 net/core/skbuff.c:2451\n  eth_header+0x44/0x1f8 net/ethernet/eth.c:83\n  dev_hard_header include/linux/netdevice.h:3188 [inline]\n  llc_mac_hdr_init+0x110/0x17c net/llc/llc_output.c:33\n  llc_sap_action_send_xid_c+0x170/0x344 net/llc/llc_s_ac.c:85\n  llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline]\n  llc_sap_next_state net/llc/llc_sap.c:182 [inline]\n  llc_sap_state_process+0x1ec/0x774 net/llc/llc_sap.c:209\n  llc_build_and_send_xid_pkt+0x12c/0x1c0 net/llc/llc_sap.c:270\n  llc_ui_sendmsg+0x7bc/0xb1c net/llc/af_llc.c:997\n  sock_sendmsg_nosec net/socket.c:730 [inline]\n  __sock_sendmsg net/socket.c:745 [inline]\n  sock_sendmsg+0x194/0x274 net/socket.c:767\n  splice_to_socket+0x7cc/0xd58 fs/splice.c:881\n  do_splice_from fs/splice.c:933 [inline]\n  direct_splice_actor+0xe4/0x1c0 fs/splice.c:1142\n  splice_direct_to_actor+0x2a0/0x7e4 fs/splice.c:1088\n  do_splice_direct+0x20c/0x348 fs/splice.c:1194\n  do_sendfile+0x4bc/0xc70 fs/read_write.c:1254\n  __do_sys_sendfile64 fs/read_write.c:1322 [inline]\n  __se_sys_sendfile64 fs/read_write.c:1308 [inline]\n  __arm64_sys_sendfile64+0x160/0x3b4 fs/read_write.c:1308\n  __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline]\n  invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51\n  el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136\n  do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155\n  el0_svc+0x54/0x158 arch/arm64/kernel/entry-common.c:678\n  el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696\n  el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:595\nCode: aa1803e6 aa1903e7 a90023f5 94792f6a (d4210000)(CVE-2024-26636)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntcp: add sanity checks to rx zerocopy\r\n\r\nTCP rx zerocopy intent is to map pages initially allocated\nfrom NIC drivers, not pages owned by a fs.\r\n\r\nThis patch adds to can_map_frag() these additional checks:\r\n\r\n- Page must not be a compound one.\n- page-\u0026gt;mapping must be NULL.\r\n\r\nThis fixes the panic reported by ZhangPeng.\r\n\r\nsyzbot was able to loopback packets built with sendfile(),\nmapping pages owned by an ext4 file to TCP rx zerocopy.\r\n\r\nr3 = socket$inet_tcp(0x2, 0x1, 0x0)\nmmap(\u0026amp;(0x7f0000ff9000/0x4000)=nil, 0x4000, 0x0, 0x12, r3, 0x0)\nr4 = socket$inet_tcp(0x2, 0x1, 0x0)\nbind$inet(r4, \u0026amp;(0x7f0000000000)={0x2, 0x4e24, @multicast1}, 0x10)\nconnect$inet(r4, \u0026amp;(0x7f00000006c0)={0x2, 0x4e24, @empty}, 0x10)\nr5 = openat$dir(0xffffffffffffff9c, \u0026amp;(0x7f00000000c0)=\u0026apos;./file0\\x00\u0026apos;,\n    0x181e42, 0x0)\nfallocate(r5, 0x0, 0x0, 0x85b8)\nsendfile(r4, r5, 0x0, 0x8ba0)\ngetsockopt$inet_tcp_TCP_ZEROCOPY_RECEIVE(r4, 0x6, 0x23,\n    \u0026amp;(0x7f00000001c0)={\u0026amp;(0x7f0000ffb000/0x3000)=nil, 0x3000, 0x0, 0x0, 0x0,\n    0x0, 0x0, 0x0, 0x0}, \u0026amp;(0x7f0000000440)=0x40)\nr6 = openat$dir(0xffffffffffffff9c, \u0026amp;(0x7f00000000c0)=\u0026apos;./file0\\x00\u0026apos;,\n    0x181e42, 0x0)(CVE-2024-26640)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()\r\n\r\nsyzbot found __ip6_tnl_rcv() could access unitiliazed data [1].\r\n\r\nCall pskb_inet_may_pull() to fix this, and initialize ipv6h\nvariable after this call as it can change skb-\u0026gt;head.\r\n\r\n[1]\n BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]\n BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]\n BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321\n  __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]\n  INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]\n  IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321\n  ip6ip6_dscp_ecn_decapsulate+0x178/0x1b0 net/ipv6/ip6_tunnel.c:727\n  __ip6_tnl_rcv+0xd4e/0x1590 net/ipv6/ip6_tunnel.c:845\n  ip6_tnl_rcv+0xce/0x100 net/ipv6/ip6_tunnel.c:888\n gre_rcv+0x143f/0x1870\n  ip6_protocol_deliver_rcu+0xda6/0x2a60 net/ipv6/ip6_input.c:438\n  ip6_input_finish net/ipv6/ip6_input.c:483 [inline]\n  NF_HOOK include/linux/netfilter.h:314 [inline]\n  ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492\n  ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586\n  dst_input include/net/dst.h:461 [inline]\n  ip6_rcv_finish+0x5db/0x870 net/ipv6/ip6_input.c:79\n  NF_HOOK include/linux/netfilter.h:314 [inline]\n  ipv6_rcv+0xda/0x390 net/ipv6/ip6_input.c:310\n  __netif_receive_skb_one_core net/core/dev.c:5532 [inline]\n  __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5646\n  netif_receive_skb_internal net/core/dev.c:5732 [inline]\n  netif_receive_skb+0x58/0x660 net/core/dev.c:5791\n  tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555\n  tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002\n  tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048\n  call_write_iter include/linux/fs.h:2084 [inline]\n  new_sync_write fs/read_write.c:497 [inline]\n  vfs_write+0x786/0x1200 fs/read_write.c:590\n  ksys_write+0x20f/0x4c0 fs/read_write.c:643\n  __do_sys_write fs/read_write.c:655 [inline]\n  __se_sys_write fs/read_write.c:652 [inline]\n  __x64_sys_write+0x93/0xd0 fs/read_write.c:652\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nUninit was created at:\n  slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768\n  slab_alloc_node mm/slub.c:3478 [inline]\n  kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523\n  kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560\n  __alloc_skb+0x318/0x740 net/core/skbuff.c:651\n  alloc_skb include/linux/skbuff.h:1286 [inline]\n  alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334\n  sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787\n  tun_alloc_skb drivers/net/tun.c:1531 [inline]\n  tun_get_user+0x1e8a/0x66d0 drivers/net/tun.c:1846\n  tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048\n  call_write_iter include/linux/fs.h:2084 [inline]\n  new_sync_write fs/read_write.c:497 [inline]\n  vfs_write+0x786/0x1200 fs/read_write.c:590\n  ksys_write+0x20f/0x4c0 fs/read_write.c:643\n  __do_sys_write fs/read_write.c:655 [inline]\n  __se_sys_write fs/read_write.c:652 [inline]\n  __x64_sys_write+0x93/0xd0 fs/read_write.c:652\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nCPU: 0 PID: 5034 Comm: syz-executor331 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023(CVE-2024-26641)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nl2tp: pass correct message length to ip6_append_data\r\n\r\nl2tp_ip6_sendmsg needs to avoid accounting for the transport header\ntwice when splicing more data into an already partially-occupied skbuff.\r\n\r\nTo manage this, we check whether the skbuff contains data using\nskb_queue_empty when deciding how much data to append using\nip6_append_data.\r\n\r\nHowever, the code which performed the calculation was incorrect:\r\n\r\n     ulen = len + skb_queue_empty(\u0026amp;sk-\u0026gt;sk_write_queue) ? transhdrlen : 0;\r\n\r\n...due to C operator precedence, this ends up setting ulen to\ntranshdrlen for messages with a non-zero length, which results in\ncorrupted packets on the wire.\r\n\r\nAdd parentheses to correct the calculation in line with the original\nintent.(CVE-2024-26752)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nIB/hfi1: Fix sdma.h tx-\u0026gt;num_descs off-by-one error\r\n\r\nUnfortunately the commit `fd8958efe877` introduced another error\ncausing the `descs` array to overflow. This reults in further crashes\neasily reproducible by `sendmsg` system call.\r\n\r\n[ 1080.836473] general protection fault, probably for non-canonical address 0x400300015528b00a: 0000 [#1] PREEMPT SMP PTI\n[ 1080.869326] RIP: 0010:hfi1_ipoib_build_ib_tx_headers.constprop.0+0xe1/0x2b0 [hfi1]\n--\n[ 1080.974535] Call Trace:\n[ 1080.976990]  \u0026lt;TASK\u0026gt;\n[ 1081.021929]  hfi1_ipoib_send_dma_common+0x7a/0x2e0 [hfi1]\n[ 1081.027364]  hfi1_ipoib_send_dma_list+0x62/0x270 [hfi1]\n[ 1081.032633]  hfi1_ipoib_send+0x112/0x300 [hfi1]\n[ 1081.042001]  ipoib_start_xmit+0x2a9/0x2d0 [ib_ipoib]\n[ 1081.046978]  dev_hard_start_xmit+0xc4/0x210\n--\n[ 1081.148347]  __sys_sendmsg+0x59/0xa0\r\n\r\ncrash\u0026gt; ipoib_txreq 0xffff9cfeba229f00\nstruct ipoib_txreq {\n  txreq = {\n    list = {\n      next = 0xffff9cfeba229f00,\n      prev = 0xffff9cfeba229f00\n    },\n    descp = 0xffff9cfeba229f40,\n    coalesce_buf = 0x0,\n    wait = 0xffff9cfea4e69a48,\n    complete = 0xffffffffc0fe0760 \u0026lt;hfi1_ipoib_sdma_complete\u0026gt;,\n    packet_len = 0x46d,\n    tlen = 0x0,\n    num_desc = 0x0,\n    desc_limit = 0x6,\n    next_descq_idx = 0x45c,\n    coalesce_idx = 0x0,\n    flags = 0x0,\n    descs = {{\n        qw = {0x8024000120dffb00, 0x4}  # SDMA_DESC0_FIRST_DESC_FLAG (bit 63)\n      }, {\n        qw = {  0x3800014231b108, 0x4}\n      }, {\n        qw = { 0x310000e4ee0fcf0, 0x8}\n      }, {\n        qw = {  0x3000012e9f8000, 0x8}\n      }, {\n        qw = {  0x59000dfb9d0000, 0x8}\n      }, {\n        qw = {  0x78000e02e40000, 0x8}\n      }}\n  },\n  sdma_hdr =  0x400300015528b000,  \u0026lt;\u0026lt;\u0026lt; invalid pointer in the tx request structure\n  sdma_status = 0x0,                   SDMA_DESC0_LAST_DESC_FLAG (bit 62)\n  complete = 0x0,\n  priv = 0x0,\n  txq = 0xffff9cfea4e69880,\n  skb = 0xffff9d099809f400\n}\r\n\r\nIf an SDMA send consists of exactly 6 descriptors and requires dword\npadding (in the 7th descriptor), the sdma_txreq descriptor array is not\nproperly expanded and the packet will overflow into the container\nstructure. This results in a panic when the send completion runs. The\nexact panic varies depending on what elements of the container structure\nget corrupted. The fix is to use the correct expression in\n_pad_sdma_tx_descs() to test the need to expand the descriptor array.\r\n\r\nWith this patch the crashes are no longer reproducible and the machine is\nstable.(CVE-2024-26766)","affected":[{"package":{"ecosystem":"openEuler:22.03-LTS-SP3","name":"kernel","purl":"pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP3"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-198.0.0.111.oe2203sp3"}]}],"ecosystem_specific":{"aarch64":["kernel-source-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm","kernel-debugsource-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm","kernel-tools-devel-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm","perf-debuginfo-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm","python3-perf-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm","kernel-debuginfo-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm","kernel-devel-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm","kernel-headers-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm","python3-perf-debuginfo-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm","kernel-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm","kernel-tools-debuginfo-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm","perf-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm","kernel-tools-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm"],"src":["kernel-5.10.0-198.0.0.111.oe2203sp3.src.rpm"],"x86_64":["kernel-debugsource-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm","kernel-devel-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm","perf-debuginfo-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm","kernel-headers-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm","kernel-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm","kernel-tools-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm","kernel-tools-debuginfo-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm","perf-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm","python3-perf-debuginfo-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm","kernel-source-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm","python3-perf-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm","kernel-tools-devel-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm","kernel-debuginfo-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1566"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47182"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47199"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47211"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52609"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52610"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52616"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52618"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26635"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26636"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26640"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26641"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26752"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26766"}],"database_specific":{"severity":"High"}}