{"schema_version":"1.7.2","id":"OESA-2024-2154","modified":"2024-09-20T11:09:10Z","published":"2024-09-20T11:09:10Z","upstream":["CVE-2024-44939","CVE-2024-44960","CVE-2024-44970","CVE-2024-44985","CVE-2024-44986","CVE-2024-44987","CVE-2024-44988","CVE-2024-45020"],"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\njfs: fix null ptr deref in dtInsertEntry\r\n\r\n[syzbot reported]\ngeneral protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]\nCPU: 0 PID: 5061 Comm: syz-executor404 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\nRIP: 0010:dtInsertEntry+0xd0c/0x1780 fs/jfs/jfs_dtree.c:3713\n...\n[Analyze]\nIn dtInsertEntry(), when the pointer h has the same value as p, after writing\nname in UniStrncpy_to_le(), p-\u0026gt;header.flag will be cleared. This will cause the\npreviously true judgment \u0026quot;p-\u0026gt;header.flag \u0026amp; BT-LEAF\u0026quot; to change to no after writing\nthe name operation, this leads to entering an incorrect branch and accessing the\nuninitialized object ih when judging this condition for the second time.\r\n\r\n[Fix]\nAfter got the page, check freelist first, if freelist == 0 then exit dtInsert()\nand return -EINVAL.(CVE-2024-44939)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: gadget: core: Check for unset descriptor\r\n\r\nMake sure the descriptor has been set before looking at maxpacket.\nThis fixes a null pointer panic in this case.\r\n\r\nThis may happen if the gadget doesn\u0026apos;t properly set up the endpoint\nfor the current speed, or the gadget descriptors are malformed and\nthe descriptor for the speed/endpoint are not found.\r\n\r\nNo current gadget driver is known to have this problem, but this\nmay cause a hard-to-find bug during development of new gadgets.(CVE-2024-44960)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5e: SHAMPO, Fix invalid WQ linked list unlink\r\n\r\nWhen all the strides in a WQE have been consumed, the WQE is unlinked\nfrom the WQ linked list (mlx5_wq_ll_pop()). For SHAMPO, it is possible\nto receive CQEs with 0 consumed strides for the same WQE even after the\nWQE is fully consumed and unlinked. This triggers an additional unlink\nfor the same wqe which corrupts the linked list.\r\n\r\nFix this scenario by accepting 0 sized consumed strides without\nunlinking the WQE again.(CVE-2024-44970)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: prevent possible UAF in ip6_xmit()\r\n\r\nIf skb_expand_head() returns NULL, skb has been freed\nand the associated dst/idev could also have been freed.\r\n\r\nWe must use rcu_read_lock() to prevent a possible UAF.(CVE-2024-44985)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: fix possible UAF in ip6_finish_output2()\r\n\r\nIf skb_expand_head() returns NULL, skb has been freed\nand associated dst/idev could also have been freed.\r\n\r\nWe need to hold rcu_read_lock() to make sure the dst and\nassociated idev are alive.(CVE-2024-44986)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: prevent UAF in ip6_send_skb()\r\n\r\nsyzbot reported an UAF in ip6_send_skb() [1]\r\n\r\nAfter ip6_local_out() has returned, we no longer can safely\ndereference rt, unless we hold rcu_read_lock().\r\n\r\nA similar issue has been fixed in commit\na688caa34beb (\u0026quot;ipv6: take rcu lock in rawv6_send_hdrinc()\u0026quot;)\r\n\r\nAnother potential issue in ip6_finish_output2() is handled in a\nseparate patch.\r\n\r\n[1]\n BUG: KASAN: slab-use-after-free in ip6_send_skb+0x18d/0x230 net/ipv6/ip6_output.c:1964\nRead of size 8 at addr ffff88806dde4858 by task syz.1.380/6530\r\n\r\nCPU: 1 UID: 0 PID: 6530 Comm: syz.1.380 Not tainted 6.11.0-rc3-syzkaller-00306-gdf6cbc62cc9b #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024\nCall Trace:\n \u0026lt;TASK\u0026gt;\n  __dump_stack lib/dump_stack.c:93 [inline]\n  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119\n  print_address_description mm/kasan/report.c:377 [inline]\n  print_report+0x169/0x550 mm/kasan/report.c:488\n  kasan_report+0x143/0x180 mm/kasan/report.c:601\n  ip6_send_skb+0x18d/0x230 net/ipv6/ip6_output.c:1964\n  rawv6_push_pending_frames+0x75c/0x9e0 net/ipv6/raw.c:588\n  rawv6_sendmsg+0x19c7/0x23c0 net/ipv6/raw.c:926\n  sock_sendmsg_nosec net/socket.c:730 [inline]\n  __sock_sendmsg+0x1a6/0x270 net/socket.c:745\n  sock_write_iter+0x2dd/0x400 net/socket.c:1160\n do_iter_readv_writev+0x60a/0x890\n  vfs_writev+0x37c/0xbb0 fs/read_write.c:971\n  do_writev+0x1b1/0x350 fs/read_write.c:1018\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f936bf79e79\nCode: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f936cd7f038 EFLAGS: 00000246 ORIG_RAX: 0000000000000014\nRAX: ffffffffffffffda RBX: 00007f936c115f80 RCX: 00007f936bf79e79\nRDX: 0000000000000001 RSI: 0000000020000040 RDI: 0000000000000004\nRBP: 00007f936bfe7916 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 0000000000000000 R14: 00007f936c115f80 R15: 00007fff2860a7a8\n \u0026lt;/TASK\u0026gt;\r\n\r\nAllocated by task 6530:\n  kasan_save_stack mm/kasan/common.c:47 [inline]\n  kasan_save_track+0x3f/0x80 mm/kasan/common.c:68\n  unpoison_slab_object mm/kasan/common.c:312 [inline]\n  __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338\n  kasan_slab_alloc include/linux/kasan.h:201 [inline]\n  slab_post_alloc_hook mm/slub.c:3988 [inline]\n  slab_alloc_node mm/slub.c:4037 [inline]\n  kmem_cache_alloc_noprof+0x135/0x2a0 mm/slub.c:4044\n  dst_alloc+0x12b/0x190 net/core/dst.c:89\n  ip6_blackhole_route+0x59/0x340 net/ipv6/route.c:2670\n  make_blackhole net/xfrm/xfrm_policy.c:3120 [inline]\n  xfrm_lookup_route+0xd1/0x1c0 net/xfrm/xfrm_policy.c:3313\n  ip6_dst_lookup_flow+0x13e/0x180 net/ipv6/ip6_output.c:1257\n  rawv6_sendmsg+0x1283/0x23c0 net/ipv6/raw.c:898\n  sock_sendmsg_nosec net/socket.c:730 [inline]\n  __sock_sendmsg+0x1a6/0x270 net/socket.c:745\n  ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597\n  ___sys_sendmsg net/socket.c:2651 [inline]\n  __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2680\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\nFreed by task 45:\n  kasan_save_stack mm/kasan/common.c:47 [inline]\n  kasan_save_track+0x3f/0x80 mm/kasan/common.c:68\n  kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579\n  poison_slab_object+0xe0/0x150 mm/kasan/common.c:240\n  __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256\n  kasan_slab_free include/linux/kasan.h:184 [inline]\n  slab_free_hook mm/slub.c:2252 [inline]\n  slab_free mm/slub.c:4473 [inline]\n  kmem_cache_free+0x145/0x350 mm/slub.c:4548\n  dst_destroy+0x2ac/0x460 net/core/dst.c:124\n  rcu_do_batch kernel/rcu/tree.c:2569 [inline]\n  rcu_core+0xafd/0x1830 kernel/rcu/tree.\n---truncated---(CVE-2024-44987)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: dsa: mv88e6xxx: Fix out-of-bound access\r\n\r\nIf an ATU violation was caused by a CPU Load operation, the SPID could\nbe larger than DSA_MAX_PORTS (the size of mv88e6xxx_chip.ports[] array).(CVE-2024-44988)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf: Fix a kernel verifier crash in stacksafe()\r\n\r\nDaniel Hodges reported a kernel verifier crash when playing with sched-ext.\nFurther investigation shows that the crash is due to invalid memory access\nin stacksafe(). More specifically, it is the following code:\r\n\r\n    if (exact != NOT_EXACT \u0026amp;\u0026amp;\n        old-\u0026gt;stack[spi].slot_type[i % BPF_REG_SIZE] !=\n        cur-\u0026gt;stack[spi].slot_type[i % BPF_REG_SIZE])\n            return false;\r\n\r\nThe \u0026apos;i\u0026apos; iterates old-\u0026gt;allocated_stack.\nIf cur-\u0026gt;allocated_stack \u0026lt; old-\u0026gt;allocated_stack the out-of-bound\naccess will happen.\r\n\r\nTo fix the issue add \u0026apos;i \u0026gt;= cur-\u0026gt;allocated_stack\u0026apos; check such that if\nthe condition is true, stacksafe() should fail. Otherwise,\ncur-\u0026gt;stack[spi].slot_type[i % BPF_REG_SIZE] memory access is legal.(CVE-2024-45020)","affected":[{"package":{"ecosystem":"openEuler:24.03-LTS","name":"kernel","purl":"pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-42.0.0.49.oe2403"}]}],"ecosystem_specific":{"aarch64":["bpftool-6.6.0-42.0.0.49.oe2403.aarch64.rpm","bpftool-debuginfo-6.6.0-42.0.0.49.oe2403.aarch64.rpm","kernel-6.6.0-42.0.0.49.oe2403.aarch64.rpm","kernel-debuginfo-6.6.0-42.0.0.49.oe2403.aarch64.rpm","kernel-debugsource-6.6.0-42.0.0.49.oe2403.aarch64.rpm","kernel-devel-6.6.0-42.0.0.49.oe2403.aarch64.rpm","kernel-headers-6.6.0-42.0.0.49.oe2403.aarch64.rpm","kernel-source-6.6.0-42.0.0.49.oe2403.aarch64.rpm","kernel-tools-6.6.0-42.0.0.49.oe2403.aarch64.rpm","kernel-tools-debuginfo-6.6.0-42.0.0.49.oe2403.aarch64.rpm","kernel-tools-devel-6.6.0-42.0.0.49.oe2403.aarch64.rpm","perf-6.6.0-42.0.0.49.oe2403.aarch64.rpm","perf-debuginfo-6.6.0-42.0.0.49.oe2403.aarch64.rpm","python3-perf-6.6.0-42.0.0.49.oe2403.aarch64.rpm","python3-perf-debuginfo-6.6.0-42.0.0.49.oe2403.aarch64.rpm"],"src":["kernel-6.6.0-42.0.0.49.oe2403.src.rpm"],"x86_64":["bpftool-6.6.0-42.0.0.49.oe2403.x86_64.rpm","bpftool-debuginfo-6.6.0-42.0.0.49.oe2403.x86_64.rpm","kernel-6.6.0-42.0.0.49.oe2403.x86_64.rpm","kernel-debuginfo-6.6.0-42.0.0.49.oe2403.x86_64.rpm","kernel-debugsource-6.6.0-42.0.0.49.oe2403.x86_64.rpm","kernel-devel-6.6.0-42.0.0.49.oe2403.x86_64.rpm","kernel-headers-6.6.0-42.0.0.49.oe2403.x86_64.rpm","kernel-source-6.6.0-42.0.0.49.oe2403.x86_64.rpm","kernel-tools-6.6.0-42.0.0.49.oe2403.x86_64.rpm","kernel-tools-debuginfo-6.6.0-42.0.0.49.oe2403.x86_64.rpm","kernel-tools-devel-6.6.0-42.0.0.49.oe2403.x86_64.rpm","perf-6.6.0-42.0.0.49.oe2403.x86_64.rpm","perf-debuginfo-6.6.0-42.0.0.49.oe2403.x86_64.rpm","python3-perf-6.6.0-42.0.0.49.oe2403.x86_64.rpm","python3-perf-debuginfo-6.6.0-42.0.0.49.oe2403.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2154"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-44939"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-44960"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-44970"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-44985"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-44986"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-44987"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-44988"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-45020"}],"database_specific":{"severity":"High"}}