{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "kernel-5.10.0-238.0.0.140.oe2203sp3.aarch64.rpm",
          "kernel-debuginfo-5.10.0-238.0.0.140.oe2203sp3.aarch64.rpm",
          "kernel-debugsource-5.10.0-238.0.0.140.oe2203sp3.aarch64.rpm",
          "kernel-devel-5.10.0-238.0.0.140.oe2203sp3.aarch64.rpm",
          "kernel-headers-5.10.0-238.0.0.140.oe2203sp3.aarch64.rpm",
          "kernel-source-5.10.0-238.0.0.140.oe2203sp3.aarch64.rpm",
          "kernel-tools-5.10.0-238.0.0.140.oe2203sp3.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-238.0.0.140.oe2203sp3.aarch64.rpm",
          "kernel-tools-devel-5.10.0-238.0.0.140.oe2203sp3.aarch64.rpm",
          "perf-5.10.0-238.0.0.140.oe2203sp3.aarch64.rpm",
          "perf-debuginfo-5.10.0-238.0.0.140.oe2203sp3.aarch64.rpm",
          "python3-perf-5.10.0-238.0.0.140.oe2203sp3.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-238.0.0.140.oe2203sp3.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-238.0.0.140.oe2203sp3.src.rpm"
        ],
        "x86_64": [
          "kernel-5.10.0-238.0.0.140.oe2203sp3.x86_64.rpm",
          "kernel-debuginfo-5.10.0-238.0.0.140.oe2203sp3.x86_64.rpm",
          "kernel-debugsource-5.10.0-238.0.0.140.oe2203sp3.x86_64.rpm",
          "kernel-devel-5.10.0-238.0.0.140.oe2203sp3.x86_64.rpm",
          "kernel-headers-5.10.0-238.0.0.140.oe2203sp3.x86_64.rpm",
          "kernel-source-5.10.0-238.0.0.140.oe2203sp3.x86_64.rpm",
          "kernel-tools-5.10.0-238.0.0.140.oe2203sp3.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-238.0.0.140.oe2203sp3.x86_64.rpm",
          "kernel-tools-devel-5.10.0-238.0.0.140.oe2203sp3.x86_64.rpm",
          "perf-5.10.0-238.0.0.140.oe2203sp3.x86_64.rpm",
          "perf-debuginfo-5.10.0-238.0.0.140.oe2203sp3.x86_64.rpm",
          "python3-perf-5.10.0-238.0.0.140.oe2203sp3.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-238.0.0.140.oe2203sp3.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:22.03-LTS-SP3",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.10.0-238.0.0.140.oe2203sp3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "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\nbonding: stop the device in bond_setup_by_slave()\r\n\r\nCommit 9eed321cde22 (\u0026quot;net: lapbether: only support ethernet devices\u0026quot;)\nhas been able to keep syzbot away from net/lapb, until today.\r\n\r\nIn the following splat [1], the issue is that a lapbether device has\nbeen created on a bonding device without members. Then adding a non\nARPHRD_ETHER member forced the bonding master to change its type.\r\n\r\nThe fix is to make sure we call dev_close() in bond_setup_by_slave()\nso that the potential linked lapbether devices (or any other devices\nhaving assumptions on the physical device) are removed.\r\n\r\nA similar bug has been addressed in commit 40baec225765\n(\u0026quot;bonding: fix panic on non-ARPHRD_ETHER enslave failure\u0026quot;)\r\n\r\n[1]\nskbuff: skb_under_panic: text:ffff800089508810 len:44 put:40 head:ffff0000c78e7c00 data:ffff0000c78e7bea tail:0x16 end:0x140 dev:bond0\nkernel BUG at net/core/skbuff.c:192 !\nInternal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP\nModules linked in:\nCPU: 0 PID: 6007 Comm: syz-executor383 Not tainted 6.6.0-rc3-syzkaller-gbf6547d8715b #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023\npstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : skb_panic net/core/skbuff.c:188 [inline]\npc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:202\nlr : skb_panic net/core/skbuff.c:188 [inline]\nlr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:202\nsp : ffff800096a06aa0\nx29: ffff800096a06ab0 x28: ffff800096a06ba0 x27: dfff800000000000\nx26: ffff0000ce9b9b50 x25: 0000000000000016 x24: ffff0000c78e7bea\nx23: ffff0000c78e7c00 x22: 000000000000002c x21: 0000000000000140\nx20: 0000000000000028 x19: ffff800089508810 x18: ffff800096a06100\nx17: 0000000000000000 x16: ffff80008a629a3c x15: 0000000000000001\nx14: 1fffe00036837a32 x13: 0000000000000000 x12: 0000000000000000\nx11: 0000000000000201 x10: 0000000000000000 x9 : cb50b496c519aa00\nx8 : cb50b496c519aa00 x7 : 0000000000000001 x6 : 0000000000000001\nx5 : ffff800096a063b8 x4 : ffff80008e280f80 x3 : ffff8000805ad11c\nx2 : 0000000000000001 x1 : 0000000100000201 x0 : 0000000000000086\nCall trace:\nskb_panic net/core/skbuff.c:188 [inline]\nskb_under_panic+0x13c/0x140 net/core/skbuff.c:202\nskb_push+0xf0/0x108 net/core/skbuff.c:2446\nip6gre_header+0xbc/0x738 net/ipv6/ip6_gre.c:1384\ndev_hard_header include/linux/netdevice.h:3136 [inline]\nlapbeth_data_transmit+0x1c4/0x298 drivers/net/wan/lapbether.c:257\nlapb_data_transmit+0x8c/0xb0 net/lapb/lapb_iface.c:447\nlapb_transmit_buffer+0x178/0x204 net/lapb/lapb_out.c:149\nlapb_send_control+0x220/0x320 net/lapb/lapb_subr.c:251\n__lapb_disconnect_request+0x9c/0x17c net/lapb/lapb_iface.c:326\nlapb_device_event+0x288/0x4e0 net/lapb/lapb_iface.c:492\nnotifier_call_chain+0x1a4/0x510 kernel/notifier.c:93\nraw_notifier_call_chain+0x3c/0x50 kernel/notifier.c:461\ncall_netdevice_notifiers_info net/core/dev.c:1970 [inline]\ncall_netdevice_notifiers_extack net/core/dev.c:2008 [inline]\ncall_netdevice_notifiers net/core/dev.c:2022 [inline]\n__dev_close_many+0x1b8/0x3c4 net/core/dev.c:1508\ndev_close_many+0x1e0/0x470 net/core/dev.c:1559\ndev_close+0x174/0x250 net/core/dev.c:1585\nlapbeth_device_event+0x2e4/0x958 drivers/net/wan/lapbether.c:466\nnotifier_call_chain+0x1a4/0x510 kernel/notifier.c:93\nraw_notifier_call_chain+0x3c/0x50 kernel/notifier.c:461\ncall_netdevice_notifiers_info net/core/dev.c:1970 [inline]\ncall_netdevice_notifiers_extack net/core/dev.c:2008 [inline]\ncall_netdevice_notifiers net/core/dev.c:2022 [inline]\n__dev_close_many+0x1b8/0x3c4 net/core/dev.c:1508\ndev_close_many+0x1e0/0x470 net/core/dev.c:1559\ndev_close+0x174/0x250 net/core/dev.c:1585\nbond_enslave+0x2298/0x30cc drivers/net/bonding/bond_main.c:2332\nbond_do_ioctl+0x268/0xc64 drivers/net/bonding/bond_main.c:4539\ndev_ifsioc+0x754/0x9ac\ndev_ioctl+0x4d8/0xd34 net/core/dev_ioctl.c:786\nsock_do_ioctl+0x1d4/0x2d0 net/socket.c:1217\nsock_ioctl+0x4e8/0x834 net/socket.c:1322\nvfs_ioctl fs/ioctl.c:51 [inline]\n__do_\n---truncated---(CVE-2023-52784)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: missing check virtio\r\n\r\nTwo missing check in virtio_net_hdr_to_skb() allowed syzbot\nto crash kernels again\r\n\r\n1. After the skb_segment function the buffer may become non-linear\n(nr_frags != 0), but since the SKBTX_SHARED_FRAG flag is not set anywhere\nthe __skb_linearize function will not be executed, then the buffer will\nremain non-linear. Then the condition (offset \u0026gt;= skb_headlen(skb))\nbecomes true, which causes WARN_ON_ONCE in skb_checksum_help.\r\n\r\n2. The struct sk_buff and struct virtio_net_hdr members must be\nmathematically related.\n(gso_size) must be greater than (needed) otherwise WARN_ON_ONCE.\n(remainder) must be greater than (needed) otherwise WARN_ON_ONCE.\n(remainder) may be 0 if division is without remainder.\r\n\r\noffset+2 (4191) \u0026gt; skb_headlen() (1116)\nWARNING: CPU: 1 PID: 5084 at net/core/dev.c:3303 skb_checksum_help+0x5e2/0x740 net/core/dev.c:3303\nModules linked in:\nCPU: 1 PID: 5084 Comm: syz-executor336 Not tainted 6.7.0-rc3-syzkaller-00014-gdf60cee26a2e #0\nHardware name: Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023\nRIP: 0010:skb_checksum_help+0x5e2/0x740 net/core/dev.c:3303\nCode: 89 e8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 52 01 00 00 44 89 e2 2b 53 74 4c 89 ee 48 c7 c7 40 57 e9 8b e8 af 8f dd f8 90 \u0026lt;0f\u0026gt; 0b 90 90 e9 87 fe ff ff e8 40 0f 6e f9 e9 4b fa ff ff 48 89 ef\nRSP: 0018:ffffc90003a9f338 EFLAGS: 00010286\nRAX: 0000000000000000 RBX: ffff888025125780 RCX: ffffffff814db209\nRDX: ffff888015393b80 RSI: ffffffff814db216 RDI: 0000000000000001\nRBP: ffff8880251257f4 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000001 R12: 000000000000045c\nR13: 000000000000105f R14: ffff8880251257f0 R15: 000000000000105d\nFS:  0000555555c24380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000000002000f000 CR3: 0000000023151000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ip_do_fragment+0xa1b/0x18b0 net/ipv4/ip_output.c:777\n ip_fragment.constprop.0+0x161/0x230 net/ipv4/ip_output.c:584\n ip_finish_output_gso net/ipv4/ip_output.c:286 [inline]\n __ip_finish_output net/ipv4/ip_output.c:308 [inline]\n __ip_finish_output+0x49c/0x650 net/ipv4/ip_output.c:295\n ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323\n NF_HOOK_COND include/linux/netfilter.h:303 [inline]\n ip_output+0x13b/0x2a0 net/ipv4/ip_output.c:433\n dst_output include/net/dst.h:451 [inline]\n ip_local_out+0xaf/0x1a0 net/ipv4/ip_output.c:129\n iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82\n ipip6_tunnel_xmit net/ipv6/sit.c:1034 [inline]\n sit_tunnel_xmit+0xed2/0x28f0 net/ipv6/sit.c:1076\n __netdev_start_xmit include/linux/netdevice.h:4940 [inline]\n netdev_start_xmit include/linux/netdevice.h:4954 [inline]\n xmit_one net/core/dev.c:3545 [inline]\n dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3561\n __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4346\n dev_queue_xmit include/linux/netdevice.h:3134 [inline]\n packet_xmit+0x257/0x380 net/packet/af_packet.c:276\n packet_snd net/packet/af_packet.c:3087 [inline]\n packet_sendmsg+0x24ca/0x5240 net/packet/af_packet.c:3119\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0xd5/0x180 net/socket.c:745\n __sys_sendto+0x255/0x340 net/socket.c:2190\n __do_sys_sendto net/socket.c:2202 [inline]\n __se_sys_sendto net/socket.c:2198 [inline]\n __x64_sys_sendto+0xe0/0x1b0 net/socket.c:2198\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x40/0x110 arch/x86/entry/common.c:82\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller(CVE-2024-43817)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: flowtable: initialise extack before use\r\n\r\nFix missing initialisation of extack in flow offload.(CVE-2024-45018)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nperf/aux: Fix AUX buffer serialization\r\n\r\nOle reported that event-\u0026gt;mmap_mutex is strictly insufficient to\nserialize the AUX buffer, add a per RB mutex to fully serialize it.\r\n\r\nNote that in the lock order comment the perf_event::mmap_mutex order\nwas already wrong, that is, it nesting under mmap_lock is not new with\nthis patch.(CVE-2024-46713)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  mm: call the security_mmap_file() LSM hook in remap_file_pages()  The remap_file_pages syscall handler calls do_mmap() directly, which doesn\u0026apos;t contain the LSM security check. And if the process has called personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for RW pages, this will actually result in remapping the pages to RWX, bypassing a W^X policy enforced by SELinux.  So we should check prot by security_mmap_file LSM hook in the remap_file_pages syscall handler before do_mmap() is called. Otherwise, it potentially permits an attacker to bypass a W^X policy enforced by SELinux.  The bypass is similar to CVE-2016-10044, which bypass the same thing via AIO and can be found in [1].  The PoC:  $ cat \u0026gt; test.c  int main(void) {  size_t pagesz = sysconf(_SC_PAGE_SIZE);  int mfd = syscall(SYS_memfd_create, \u0026quot;test\u0026quot;, 0);  const char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE,   MAP_SHARED, mfd, 0);  unsigned int old = syscall(SYS_personality, 0xffffffff);  syscall(SYS_personality, READ_IMPLIES_EXEC | old);  syscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0);  syscall(SYS_personality, old);  // show the RWX page exists even if W^X policy is enforced  int fd = open(\u0026quot;/proc/self/maps\u0026quot;, O_RDONLY);  unsigned char buf2[1024];  while (1) {   int ret = read(fd, buf2, 1024);   if (ret \u0026lt;= 0) break;   write(1, buf2, ret);  }  close(fd); }  $ gcc test.c -o test $ ./test | grep rwx 7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted)  [PM: subject line tweaks](CVE-2024-47745)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race Condition  In the ether3_probe function, a timer is initialized with a callback function ether3_ledoff, bound to \u0026amp;prev(dev)-\u0026gt;timer. Once the timer is started, there is a risk of a race condition if the module or device is removed, triggering the ether3_remove function to perform cleanup. The sequence of operations that may lead to a UAF bug is as follows:  CPU0                                    CPU1                        |  ether3_ledoff ether3_remove         |   free_netdev(dev);   |   put_devic           |   kfree(dev);         |  |  ether3_outw(priv(dev)-\u0026gt;regs.config2 |= CFG2_CTRLO, REG_CONFIG2);                       | // use dev  Fix it by ensuring that the timer is canceled before proceeding with the cleanup in ether3_remove.(CVE-2024-47747)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  RDMA/cxgb4: Added NULL check for lookup_atid  The lookup_atid() function can return NULL if the ATID is invalid or does not exist in the identifier table, which could lead to dereferencing a null pointer without a check in the `act_establish()` and `act_open_rpl()` functions. Add a NULL check to prevent null pointer dereferencing.  Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-47749)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Initialize denominators\u0026apos; default to 1  [WHAT \u0026amp; HOW] Variables used as denominators and maybe not assigned to other values, should not be 0. Change their default to 1 so they are never 0.  This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.(CVE-2024-49899)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  wifi: iwlwifi: mvm: avoid NULL pointer dereference  iwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvsta pointer is not NULL. It retrieves this pointer using iwl_mvm_sta_from_mac80211, which is dereferencing the ieee80211_sta pointer. If sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULL pointer. Fix this by checking the sta pointer before retrieving the mvmsta from it. If sta is not NULL, then mvmsta isn\u0026apos;t either.(CVE-2024-49929)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  netfilter: nf_tables: prevent nf_skb_duplicated corruption  syzbot found that nf_dup_ipv4() or nf_dup_ipv6() could write per-cpu variable nf_skb_duplicated in an unsafe way [1].  Disabling preemption as hinted by the splat is not enough, we have to disable soft interrupts as well.  [1] BUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316  caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace:  \u0026lt;TASK\u0026gt;   __dump_stack lib/dump_stack.c:93 [inline]   dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119   check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49   nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87   nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30   expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]   nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288   nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23   nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]   nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626   nf_hook+0x2c4/0x450 include/linux/netfilter.h:269   NF_HOOK_COND include/linux/netfilter.h:302 [inline]   ip_output+0x185/0x230 net/ipv4/ip_output.c:433   ip_local_out net/ipv4/ip_output.c:129 [inline]   ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495   udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981   udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269   sock_sendmsg_nosec net/socket.c:730 [inline]   __sock_sendmsg+0x1a6/0x270 net/socket.c:745   ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597   ___sys_sendmsg net/socket.c:2651 [inline]   __sys_sendmmsg+0x3b2/0x740 net/socket.c:2737   __do_sys_sendmmsg net/socket.c:2766 [inline]   __se_sys_sendmmsg net/socket.c:2763 [inline]   __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763   do_syscall_x64 arch/x86/entry/common.c:52 [inline]   do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f4ce4f7def9 Code: 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 RSP: 002b:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9 RDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006 RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68  \u0026lt;/TASK\u0026gt;(CVE-2024-49952)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  netfilter: br_netfilter: fix panic with metadata_dst skb  Fix a kernel panic in the br_netfilter module when sending untagged traffic via a VxLAN device. This happens during the check for fragmentation in br_nf_dev_queue_xmit.  It is dependent on: 1) the br_netfilter module being loaded; 2) net.bridge.bridge-nf-call-iptables set to 1; 3) a bridge with a VxLAN (single-vxlan-device) netdevice as a bridge port; 4) untagged frames with size higher than the VxLAN MTU forwarded/flooded  When forwarding the untagged packet to the VxLAN bridge port, before the netfilter hooks are called, br_handle_egress_vlan_tunnel is called and changes the skb_dst to the tunnel dst. The tunnel_dst is a metadata type of dst, i.e., skb_valid_dst(skb) is false, and metadata-\u0026gt;dst.dev is NULL.  Then in the br_netfilter hooks, in br_nf_dev_queue_xmit, there\u0026apos;s a check for frames that needs to be fragmented: frames with higher MTU than the VxLAN device end up calling br_nf_ip_fragment, which in turns call ip_skb_dst_mtu.  The ip_dst_mtu tries to use the skb_dst(skb) as if it was a valid dst with valid dst-\u0026gt;dev, thus the crash.  This case was never supported in the first place, so drop the packet instead.  PING 10.0.0.2 (10.0.0.2) from 0.0.0.0 h1-eth0: 2000(2028) bytes of data. [  176.291791] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000110 [  176.292101] Mem abort info: [  176.292184]   ESR = 0x0000000096000004 [  176.292322]   EC = 0x25: DABT (current EL), IL = 32 bits [  176.292530]   SET = 0, FnV = 0 [  176.292709]   EA = 0, S1PTW = 0 [  176.292862]   FSC = 0x04: level 0 translation fault [  176.293013] Data abort info: [  176.293104]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [  176.293488]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [  176.293787]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [  176.293995] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000043ef5000 [  176.294166] [0000000000000110] pgd=0000000000000000, p4d=0000000000000000 [  176.294827] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [  176.295252] Modules linked in: vxlan ip6_udp_tunnel udp_tunnel veth br_netfilter bridge stp llc ipv6 crct10dif_ce [  176.295923] CPU: 0 PID: 188 Comm: ping Not tainted 6.8.0-rc3-g5b3fbd61b9d1 #2 [  176.296314] Hardware name: linux,dummy-virt (DT) [  176.296535] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [  176.296808] pc : br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [  176.297382] lr : br_nf_dev_queue_xmit+0x2ac/0x4ec [br_netfilter] [  176.297636] sp : ffff800080003630 [  176.297743] x29: ffff800080003630 x28: 0000000000000008 x27: ffff6828c49ad9f8 [  176.298093] x26: ffff6828c49ad000 x25: 0000000000000000 x24: 00000000000003e8 [  176.298430] x23: 0000000000000000 x22: ffff6828c4960b40 x21: ffff6828c3b16d28 [  176.298652] x20: ffff6828c3167048 x19: ffff6828c3b16d00 x18: 0000000000000014 [  176.298926] x17: ffffb0476322f000 x16: ffffb7e164023730 x15: 0000000095744632 [  176.299296] x14: ffff6828c3f1c880 x13: 0000000000000002 x12: ffffb7e137926a70 [  176.299574] x11: 0000000000000001 x10: ffff6828c3f1c898 x9 : 0000000000000000 [  176.300049] x8 : ffff6828c49bf070 x7 : 0008460f18d5f20e x6 : f20e0100bebafeca [  176.300302] x5 : ffff6828c7f918fe x4 : ffff6828c49bf070 x3 : 0000000000000000 [  176.300586] x2 : 0000000000000000 x1 : ffff6828c3c7ad00 x0 : ffff6828c7f918f0 [  176.300889] Call trace: [  176.301123]  br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [  176.301411]  br_nf_post_routing+0x2a8/0x3e4 [br_netfilter] [  176.301703]  nf_hook_slow+0x48/0x124 [  176.302060]  br_forward_finish+0xc8/0xe8 [bridge] [  176.302371]  br_nf_hook_thresh+0x124/0x134 [br_netfilter] [  176.302605]  br_nf_forward_finish+0x118/0x22c [br_netfilter] [  176.302824]  br_nf_forward_ip.part.0+0x264/0x290 [br_netfilter] [  176.303136]  br_nf_forward+0x2b8/0x4e0 [br_netfilter] [  176.303359]  nf_hook_slow+0x48/0x124 [  176.303 ---truncated---(CVE-2024-50045)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  RDMA/rtrs-srv: Avoid null pointer deref during path establishment  For RTRS path establishment, RTRS client initiates and completes con_num of connections. After establishing all its connections, the information is exchanged between the client and server through the info_req message. During this exchange, it is essential that all connections have been established, and the state of the RTRS srv path is CONNECTED.  So add these sanity checks, to make sure we detect and abort process in error scenarios to avoid null pointer deref.(CVE-2024-50062)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  mptcp: pm: fix UaF read in mptcp_pm_nl_rm_addr_or_subflow  Syzkaller reported this splat:    ==================================================================   BUG: KASAN: slab-use-after-free in mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881   Read of size 4 at addr ffff8880569ac858 by task syz.1.2799/14662    CPU: 0 UID: 0 PID: 14662 Comm: syz.1.2799 Not tainted 6.12.0-rc2-syzkaller-00307-g36c254515dc6 #0   Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014   Call Trace:    \u0026lt;TASK\u0026gt;    __dump_stack lib/dump_stack.c:94 [inline]    dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120    print_address_description mm/kasan/report.c:377 [inline]    print_report+0xc3/0x620 mm/kasan/report.c:488    kasan_report+0xd9/0x110 mm/kasan/report.c:601    mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881    mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:914 [inline]    mptcp_nl_remove_id_zero_address+0x305/0x4a0 net/mptcp/pm_netlink.c:1572    mptcp_pm_nl_del_addr_doit+0x5c9/0x770 net/mptcp/pm_netlink.c:1603    genl_family_rcv_msg_doit+0x202/0x2f0 net/netlink/genetlink.c:1115    genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]    genl_rcv_msg+0x565/0x800 net/netlink/genetlink.c:1210    netlink_rcv_skb+0x165/0x410 net/netlink/af_netlink.c:2551    genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219    netlink_unicast_kernel net/netlink/af_netlink.c:1331 [inline]    netlink_unicast+0x53c/0x7f0 net/netlink/af_netlink.c:1357    netlink_sendmsg+0x8b8/0xd70 net/netlink/af_netlink.c:1901    sock_sendmsg_nosec net/socket.c:729 [inline]    __sock_sendmsg net/socket.c:744 [inline]    ____sys_sendmsg+0x9ae/0xb40 net/socket.c:2607    ___sys_sendmsg+0x135/0x1e0 net/socket.c:2661    __sys_sendmsg+0x117/0x1f0 net/socket.c:2690    do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline]    __do_fast_syscall_32+0x73/0x120 arch/x86/entry/common.c:386    do_fast_syscall_32+0x32/0x80 arch/x86/entry/common.c:411    entry_SYSENTER_compat_after_hwframe+0x84/0x8e   RIP: 0023:0xf7fe4579   Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 \u0026lt;5d\u0026gt; 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00   RSP: 002b:00000000f574556c EFLAGS: 00000296 ORIG_RAX: 0000000000000172   RAX: ffffffffffffffda RBX: 000000000000000b RCX: 0000000020000140   RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000   RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000   R10: 0000000000000000 R11: 0000000000000296 R12: 0000000000000000   R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000    \u0026lt;/TASK\u0026gt;    Allocated by task 5387:    kasan_save_stack+0x33/0x60 mm/kasan/common.c:47    kasan_save_track+0x14/0x30 mm/kasan/common.c:68    poison_kmalloc_redzone mm/kasan/common.c:377 [inline]    __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394    kmalloc_noprof include/linux/slab.h:878 [inline]    kzalloc_noprof include/linux/slab.h:1014 [inline]    subflow_create_ctx+0x87/0x2a0 net/mptcp/subflow.c:1803    subflow_ulp_init+0xc3/0x4d0 net/mptcp/subflow.c:1956    __tcp_set_ulp net/ipv4/tcp_ulp.c:146 [inline]    tcp_set_ulp+0x326/0x7f0 net/ipv4/tcp_ulp.c:167    mptcp_subflow_create_socket+0x4ae/0x10a0 net/mptcp/subflow.c:1764    __mptcp_subflow_connect+0x3cc/0x1490 net/mptcp/subflow.c:1592    mptcp_pm_create_subflow_or_signal_addr+0xbda/0x23a0 net/mptcp/pm_netlink.c:642    mptcp_pm_nl_fully_established net/mptcp/pm_netlink.c:650 [inline]    mptcp_pm_nl_work+0x3a1/0x4f0 net/mptcp/pm_netlink.c:943    mptcp_worker+0x15a/0x1240 net/mptcp/protocol.c:2777    process_one_work+0x958/0x1b30 kernel/workqueue.c:3229    process_scheduled_works kernel/workqueue.c:3310 [inline]    worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391    kthread+0x2c1/0x3a0 kernel/kthread.c:389    ret_from_fork+0x45/0x80 arch/x86/ke ---truncated---(CVE-2024-50085)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  unicode: Don\u0026apos;t special case ignorable code points  We don\u0026apos;t need to handle them separately. Instead, just let them decompose/casefold to themselves.(CVE-2024-50089)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context  PRMT needs to find the correct type of block to translate the PA-VA mapping for EFI runtime services.  The issue arises because the PRMT is finding a block of type EFI_CONVENTIONAL_MEMORY, which is not appropriate for runtime services as described in Section 2.2.2 (Runtime Services) of the UEFI Specification [1]. Since the PRM handler is a type of runtime service, this causes an exception when the PRM handler is called.      [Firmware Bug]: Unable to handle paging request in EFI runtime service     WARNING: CPU: 22 PID: 4330 at drivers/firmware/efi/runtime-wrappers.c:341         __efi_queue_work+0x11c/0x170     Call trace:  Let PRMT find a block with EFI_MEMORY_RUNTIME for PRM handler and PRM context.  If no suitable block is found, a warning message will be printed, but the procedure continues to manage the next PRM handler.  However, if the PRM handler is actually called without proper allocation, it would result in a failure during error handling.  By using the correct memory types for runtime services, ensure that the PRM handler and the context are properly mapped in the virtual address space during runtime, preventing the paging request error.  The issue is really that only memory that has been remapped for runtime by the firmware can be used by the PRM handler, and so the region needs to have the EFI_MEMORY_RUNTIME attribute.  [ rjw: Subject and changelog edits ](CVE-2024-50141)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  udf: fix uninit-value use in udf_get_fileshortad  Check for overflow when computing alen in udf_current_aext to mitigate later uninit-value use in udf_get_fileshortad KMSAN bug[1]. After applying the patch reproducer did not trigger any issue[2].  [1] https://syzkaller.appspot.com/bug?extid=8901c4560b7ab5c2f9df [2] https://syzkaller.appspot.com/x/log.txt?x=10242227980000(CVE-2024-50143)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ceph: remove the incorrect Fw reference check when dirtying pages  When doing the direct-io reads it will also try to mark pages dirty, but for the read path it won\u0026apos;t hold the Fw caps and there is case will it get the Fw reference.(CVE-2024-50179)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  fbdev: sisfb: Fix strbuf array overflow  The values of the variables xres and yres are placed in strbuf. These variables are obtained from strbuf1. The strbuf1 array contains digit characters and a space if the array contains non-digit characters. Then, when executing sprintf(strbuf, \u0026quot;%ux%ux8\u0026quot;, xres, yres); more than 16 bytes will be written to strbuf. It is suggested to increase the size of the strbuf array to 24.  Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-50180)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  irqchip/gic-v4: Don\u0026apos;t allow a VMOVP on a dying VPE  Kunkun Jiang reported that there is a small window of opportunity for userspace to force a change of affinity for a VPE while the VPE has already been unmapped, but the corresponding doorbell interrupt still visible in /proc/irq/.  Plug the race by checking the value of vmapp_count, which tracks whether the VPE is mapped ot not, and returning an error in this case.  This involves making vmapp_count common to both GICv4.1 and its v4.0 ancestor.(CVE-2024-50192)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  posix-clock: Fix missing timespec64 check in pc_clock_settime()  As Andrew pointed out, it will make sense that the PTP core checked timespec64 struct\u0026apos;s tv_sec and tv_nsec range before calling ptp-\u0026gt;info-\u0026gt;settime64().  As the man manual of clock_settime() said, if tp.tv_sec is negative or tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL, which include dynamic clocks which handles PTP clock, and the condition is consistent with timespec64_valid(). As Thomas suggested, timespec64_valid() only check the timespec is valid, but not ensure that the time is in a valid range, so check it ahead using timespec64_valid_strict() in pc_clock_settime() and return -EINVAL if not valid.  There are some drivers that use tp-\u0026gt;tv_sec and tp-\u0026gt;tv_nsec directly to write registers without validity checks and assume that the higher layer has checked it, which is dangerous and will benefit from this, such as hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(), and some drivers can remove the checks of itself.(CVE-2024-50195)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  nilfs2: propagate directory read errors from nilfs_find_entry()  Syzbot reported that a task hang occurs in vcs_open() during a fuzzing test for nilfs2.  The root cause of this problem is that in nilfs_find_entry(), which searches for directory entries, ignores errors when loading a directory page/folio via nilfs_get_folio() fails.  If the filesystem images is corrupted, and the i_size of the directory inode is large, and the directory page/folio is successfully read but fails the sanity check, for example when it is zero-filled, nilfs_check_folio() may continue to spit out error messages in bursts.  Fix this issue by propagating the error to the callers when loading a page/folio fails in nilfs_find_entry().  The current interface of nilfs_find_entry() and its callers is outdated and cannot propagate error codes such as -EIO and -ENOMEM returned via nilfs_find_entry(), so fix it together.(CVE-2024-50202)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ALSA: firewire-lib: Avoid division by zero in apply_constraint_to_size()  The step variable is initialized to zero. It is changed in the loop, but if it\u0026apos;s not changed it will remain zero. Add a variable check before the division.  The observed behavior was introduced by commit 826b5de90c0b (\u0026quot;ALSA: firewire-lib: fix insufficient PCM rule for period/buffer size\u0026quot;), and it is difficult to show that any of the interval parameters will satisfy the snd_interval_test() condition with data from the amdtp_rate_table[] table.  Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-50205)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  nilfs2: fix potential deadlock with newly created symlinks  Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers memory reclamation involving the filesystem layer, which can result in circular lock dependencies among the reader/writer semaphore nilfs-\u0026gt;ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the fs_reclaim pseudo lock.  This is because after commit 21fc61c73c39 (\u0026quot;don\u0026apos;t put symlink bodies in pagecache into highmem\u0026quot;), the gfp flags of the page cache for symbolic links are overwritten to GFP_KERNEL via inode_nohighmem().  This is not a problem for symlinks read from the backing device, because the __GFP_FS flag is dropped after inode_nohighmem() is called.  However, when a new symlink is created with nilfs_symlink(), the gfp flags remain overwritten to GFP_KERNEL.  Then, memory allocation called from page_symlink() etc.  triggers memory reclamation including the FS layer, which may call nilfs_evict_inode() or nilfs_dirty_inode().  And these can cause a deadlock if they are called while nilfs-\u0026gt;ns_segctor_sem is held:  Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags of newly created symlinks in the same way that nilfs_new_inode() and __nilfs_read_inode() do, as a workaround until we adopt nofs allocation scope consistently or improve the locking constraints.(CVE-2024-50229)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  nilfs2: fix kernel bug due to missing clearing of checked flag  Syzbot reported that in directory operations after nilfs2 detects filesystem corruption and degrades to read-only, __block_write_begin_int(), which is called to prepare block writes, may fail the BUG_ON check for accesses exceeding the folio/page size, triggering a kernel bug.  This was found to be because the \u0026quot;checked\u0026quot; flag of a page/folio was not cleared when it was discarded by nilfs2\u0026apos;s own routine, which causes the sanity check of directory entries to be skipped when the directory page/folio is reloaded.  So, fix that.  This was necessary when the use of nilfs2\u0026apos;s own page discard routine was applied to more than just metadata files.(CVE-2024-50230)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  NFSD: Initialize struct nfsd4_copy earlier  Ensure the refcount and async_copies fields are initialized early. cleanup_async_copy() will reference these fields if an error occurs in nfsd4_copy(). If they are not correctly initialized, at the very least, a refcount underflow occurs.(CVE-2024-50241)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ntfs3: Add bounds checking to mi_enum_attr()  Added bounds checking to make sure that every attr don\u0026apos;t stray beyond valid memory region.(CVE-2024-50248)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  bpf: Fix out-of-bounds write in trie_get_next_key()  trie_get_next_key() allocates a node stack with size trie-\u0026gt;max_prefixlen, while it writes (trie-\u0026gt;max_prefixlen + 1) nodes to the stack when it has full paths from the root to leaves. For example, consider a trie with max_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ... 0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with .prefixlen = 8 make 9 nodes be written on the node stack with size 8.(CVE-2024-50262)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove()  Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove():  [   57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12 [   57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper.  Leaking 1 clusters and removing the entry [   57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004 [...] [   57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [...] [   57.331328] Call Trace: [   57.331477]  \u0026lt;TASK\u0026gt; [...] [   57.333511]  ? do_user_addr_fault+0x3e5/0x740 [   57.333778]  ? exc_page_fault+0x70/0x170 [   57.334016]  ? asm_exc_page_fault+0x2b/0x30 [   57.334263]  ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10 [   57.334596]  ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [   57.334913]  ocfs2_xa_remove_entry+0x23/0xc0 [   57.335164]  ocfs2_xa_set+0x704/0xcf0 [   57.335381]  ? _raw_spin_unlock+0x1a/0x40 [   57.335620]  ? ocfs2_inode_cache_unlock+0x16/0x20 [   57.335915]  ? trace_preempt_on+0x1e/0x70 [   57.336153]  ? start_this_handle+0x16c/0x500 [   57.336410]  ? preempt_count_sub+0x50/0x80 [   57.336656]  ? _raw_read_unlock+0x20/0x40 [   57.336906]  ? start_this_handle+0x16c/0x500 [   57.337162]  ocfs2_xattr_block_set+0xa6/0x1e0 [   57.337424]  __ocfs2_xattr_set_handle+0x1fd/0x5d0 [   57.337706]  ? ocfs2_start_trans+0x13d/0x290 [   57.337971]  ocfs2_xattr_set+0xb13/0xfb0 [   57.338207]  ? dput+0x46/0x1c0 [   57.338393]  ocfs2_xattr_trusted_set+0x28/0x30 [   57.338665]  ? ocfs2_xattr_trusted_set+0x28/0x30 [   57.338948]  __vfs_removexattr+0x92/0xc0 [   57.339182]  __vfs_removexattr_locked+0xd5/0x190 [   57.339456]  ? preempt_count_sub+0x50/0x80 [   57.339705]  vfs_removexattr+0x5f/0x100 [...]  Reproducer uses faultinject facility to fail ocfs2_xa_remove() -\u0026gt; ocfs2_xa_value_truncate() with -ENOMEM.  In this case the comment mentions that we can return 0 if ocfs2_xa_cleanup_value_truncate() is going to wipe the entry anyway. But the following \u0026apos;rc\u0026apos; check is wrong and execution flow do \u0026apos;ocfs2_xa_remove_entry(loc);\u0026apos; twice: * 1st: in ocfs2_xa_cleanup_value_truncate(); * 2nd: returning back to ocfs2_xa_remove() instead of going to \u0026apos;out\u0026apos;.  Fix this by skipping the 2nd removal of the same entry and making syzkaller repro happy.(CVE-2024-50265)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  usb: musb: sunxi: Fix accessing an released usb phy  Commit 6ed05c68cbca (\u0026quot;usb: musb: sunxi: Explicitly release USB PHY on exit\u0026quot;) will cause that usb phy @glue-\u0026gt;xceiv is accessed after released.  1) register platform driver @sunxi_musb_driver // get the usb phy @glue-\u0026gt;xceiv sunxi_musb_probe() -\u0026gt; devm_usb_get_phy().  2) register and unregister platform driver @musb_driver musb_probe() -\u0026gt; sunxi_musb_init() use the phy here //the phy is released here musb_remove() -\u0026gt; sunxi_musb_exit() -\u0026gt; devm_usb_put_phy()  3) register @musb_driver again musb_probe() -\u0026gt; sunxi_musb_init() use the phy here but the phy has been released at 2). ...  Fixed by reverting the commit, namely, removing devm_usb_put_phy() from sunxi_musb_exit().(CVE-2024-50269)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  btrfs: reinitialize delayed ref list after deleting it from the list  At insert_delayed_ref() if we need to update the action of an existing ref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head\u0026apos;s ref_add_list using list_del(), which leaves the ref\u0026apos;s add_list member not reinitialized, as list_del() sets the next and prev members of the list to LIST_POISON1 and LIST_POISON2, respectively.  If later we end up calling drop_delayed_ref() against the ref, which can happen during merging or when destroying delayed refs due to a transaction abort, we can trigger a crash since at drop_delayed_ref() we call list_empty() against the ref\u0026apos;s add_list, which returns false since the list was not reinitialized after the list_del() and as a consequence we call list_del() again at drop_delayed_ref(). This results in an invalid list access since the next and prev members are set to poison pointers, resulting in a splat if CONFIG_LIST_HARDENED and CONFIG_DEBUG_LIST are set or invalid poison pointer dereferences otherwise.  So fix this by deleting from the list with list_del_init() instead.(CVE-2024-50273)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  media: av7110: fix a spectre vulnerability  As warned by smatch:  drivers/staging/media/av7110/av7110_ca.c:270 dvb_ca_ioctl() warn: potential spectre issue \u0026apos;av7110-\u0026gt;ci_slot\u0026apos; [w] (local cap)  There is a spectre-related vulnerability at the code. Fix it.(CVE-2024-50289)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  security/keys: fix slab-out-of-bounds in key_task_permission  KASAN reports an out of bounds read: BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36 BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline] BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410 security/keys/permission.c:54 Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362  CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 Call Trace:  __dump_stack lib/dump_stack.c:82 [inline]  dump_stack+0x107/0x167 lib/dump_stack.c:123  print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400  __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560  kasan_report+0x3a/0x50 mm/kasan/report.c:585  __kuid_val include/linux/uidgid.h:36 [inline]  uid_eq include/linux/uidgid.h:63 [inline]  key_task_permission+0x394/0x410 security/keys/permission.c:54  search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793  This issue was also reported by syzbot.  It can be reproduced by following these steps(more details [1]): 1. Obtain more than 32 inputs that have similar hashes, which ends with the    pattern \u0026apos;0xxxxxxxe6\u0026apos;. 2. Reboot and add the keys obtained in step 1.  The reproducer demonstrates how this issue happened: 1. In the search_nested_keyrings function, when it iterates through the    slots in a node(below tag ascend_to_node), if the slot pointer is meta    and node-\u0026gt;back_pointer != NULL(it means a root), it will proceed to    descend_to_node. However, there is an exception. If node is the root,    and one of the slots points to a shortcut, it will be treated as a    keyring. 2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function.    However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as    ASSOC_ARRAY_PTR_SUBTYPE_MASK. 3. When 32 keys with the similar hashes are added to the tree, the ROOT    has keys with hashes that are not similar (e.g. slot 0) and it splits    NODE A without using a shortcut. When NODE A is filled with keys that    all hashes are xxe6, the keys are similar, NODE A will split with a    shortcut. Finally, it forms the tree as shown below, where slot 6 points    to a shortcut.                        NODE A               +------\u0026gt;+---+       ROOT    |       | 0 | xxe6       +---+   |       +---+  xxxx | 0 | shortcut  :   : xxe6       +---+   |       +---+  xxe6 :   :   |       |   | xxe6       +---+   |       +---+       | 6 |---+       :   : xxe6       +---+           +---+  xxe6 :   :           | f | xxe6       +---+           +---+  xxe6 | f |       +---+  4. As mentioned above, If a slot(slot 6) of the root points to a shortcut,    it may be mistakenly transferred to a key*, leading to a read    out-of-bounds read.  To fix this issue, one should jump to descend_to_node if the ptr is a shortcut, regardless of whether the node is root or not.  [1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/  [jarkko: tweaked the commit message a bit to have an appropriate closes  tag.](CVE-2024-50301)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  io_uring/rw: fix missing NOWAIT check for O_DIRECT start write  When io_uring starts a write, it\u0026apos;ll call kiocb_start_write() to bump the super block rwsem, preventing any freezes from happening while that write is in-flight. The freeze side will grab that rwsem for writing, excluding any new writers from happening and waiting for existing writes to finish. But io_uring unconditionally uses kiocb_start_write(), which will block if someone is currently attempting to freeze the mount point. This causes a deadlock where freeze is waiting for previous writes to complete, but the previous writes cannot complete, as the task that is supposed to complete them is blocked waiting on starting a new write. This results in the following stuck trace showing that dependency with the write blocked starting a new write:  task:fio             state:D stack:0     pid:886   tgid:886   ppid:876 Call trace:  __switch_to+0x1d8/0x348  __schedule+0x8e8/0x2248  schedule+0x110/0x3f0  percpu_rwsem_wait+0x1e8/0x3f8  __percpu_down_read+0xe8/0x500  io_write+0xbb8/0xff8  io_issue_sqe+0x10c/0x1020  io_submit_sqes+0x614/0x2110  __arm64_sys_io_uring_enter+0x524/0x1038  invoke_syscall+0x74/0x268  el0_svc_common.constprop.0+0x160/0x238  do_el0_svc+0x44/0x60  el0_svc+0x44/0xb0  el0t_64_sync_handler+0x118/0x128  el0t_64_sync+0x168/0x170 INFO: task fsfreeze:7364 blocked for more than 15 seconds.       Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963  with the attempting freezer stuck trying to grab the rwsem:  task:fsfreeze        state:D stack:0     pid:7364  tgid:7364  ppid:995 Call trace:  __switch_to+0x1d8/0x348  __schedule+0x8e8/0x2248  schedule+0x110/0x3f0  percpu_down_write+0x2b0/0x680  freeze_super+0x248/0x8a8  do_vfs_ioctl+0x149c/0x1b18  __arm64_sys_ioctl+0xd0/0x1a0  invoke_syscall+0x74/0x268  el0_svc_common.constprop.0+0x160/0x238  do_el0_svc+0x44/0x60  el0_svc+0x44/0xb0  el0t_64_sync_handler+0x118/0x128  el0t_64_sync+0x168/0x170  Fix this by having the io_uring side honor IOCB_NOWAIT, and only attempt a blocking grab of the super block rwsem if it isn\u0026apos;t set. For normal issue where IOCB_NOWAIT would always be set, this returns -EAGAIN which will have io_uring core issue a blocking attempt of the write. That will in turn also get completions run, ensuring forward progress.  Since freezing requires CAP_SYS_ADMIN in the first place, this isn\u0026apos;t something that can be triggered by a regular user.(CVE-2024-53052)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  media: s5p-jpeg: prevent buffer overflows  The current logic allows word to be less than 2. If this happens, there will be buffer overflows, as reported by smatch. Add extra checks to prevent it.  While here, remove an unused word = 0 assignment.(CVE-2024-53061)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  nfs: Fix KMSAN warning in decode_getfattr_attrs()  Fix the following KMSAN warning:  CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G    B Tainted: [B]=BAD_PAGE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) ===================================================== ===================================================== BUG: KMSAN: uninit-value in decode_getfattr_attrs+0x2d6d/0x2f90  decode_getfattr_attrs+0x2d6d/0x2f90  decode_getfattr_generic+0x806/0xb00  nfs4_xdr_dec_getattr+0x1de/0x240  rpcauth_unwrap_resp_decode+0xab/0x100  rpcauth_unwrap_resp+0x95/0xc0  call_decode+0x4ff/0xb50  __rpc_execute+0x57b/0x19d0  rpc_execute+0x368/0x5e0  rpc_run_task+0xcfe/0xee0  nfs4_proc_getattr+0x5b5/0x990  __nfs_revalidate_inode+0x477/0xd00  nfs_access_get_cached+0x1021/0x1cc0  nfs_do_access+0x9f/0xae0  nfs_permission+0x1e4/0x8c0  inode_permission+0x356/0x6c0  link_path_walk+0x958/0x1330  path_lookupat+0xce/0x6b0  filename_lookup+0x23e/0x770  vfs_statx+0xe7/0x970  vfs_fstatat+0x1f2/0x2c0  __se_sys_newfstatat+0x67/0x880  __x64_sys_newfstatat+0xbd/0x120  x64_sys_call+0x1826/0x3cf0  do_syscall_64+0xd0/0x1b0  entry_SYSCALL_64_after_hwframe+0x77/0x7f  The KMSAN warning is triggered in decode_getfattr_attrs(), when calling decode_attr_mdsthreshold(). It appears that fattr-\u0026gt;mdsthreshold is not initialized.  Fix the issue by initializing fattr-\u0026gt;mdsthreshold to NULL in nfs_fattr_init().(CVE-2024-53066)",
  "id": "OESA-2024-2494",
  "modified": "2026-08-06T11:07:58Z",
  "published": "2024-11-29T11:07:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2494"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52784"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43817"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45018"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46713"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47745"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47747"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47749"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49899"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49929"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49952"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50045"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50062"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50085"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50089"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50141"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50143"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50179"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50180"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50192"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50195"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50202"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50205"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50229"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50230"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50241"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50248"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50262"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50265"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50269"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50273"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50289"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50301"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53052"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53061"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53066"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2023-52784",
    "CVE-2024-43817",
    "CVE-2024-45018",
    "CVE-2024-46713",
    "CVE-2024-47745",
    "CVE-2024-47747",
    "CVE-2024-47749",
    "CVE-2024-49899",
    "CVE-2024-49929",
    "CVE-2024-49952",
    "CVE-2024-50045",
    "CVE-2024-50062",
    "CVE-2024-50085",
    "CVE-2024-50089",
    "CVE-2024-50141",
    "CVE-2024-50143",
    "CVE-2024-50179",
    "CVE-2024-50180",
    "CVE-2024-50192",
    "CVE-2024-50195",
    "CVE-2024-50202",
    "CVE-2024-50205",
    "CVE-2024-50229",
    "CVE-2024-50230",
    "CVE-2024-50241",
    "CVE-2024-50248",
    "CVE-2024-50262",
    "CVE-2024-50265",
    "CVE-2024-50269",
    "CVE-2024-50273",
    "CVE-2024-50289",
    "CVE-2024-50301",
    "CVE-2024-53052",
    "CVE-2024-53061",
    "CVE-2024-53066"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-4.19.90-2411.5.0.0305.oe2003sp4.aarch64.rpm",
          "bpftool-debuginfo-4.19.90-2411.5.0.0305.oe2003sp4.aarch64.rpm",
          "kernel-4.19.90-2411.5.0.0305.oe2003sp4.aarch64.rpm",
          "kernel-debuginfo-4.19.90-2411.5.0.0305.oe2003sp4.aarch64.rpm",
          "kernel-debugsource-4.19.90-2411.5.0.0305.oe2003sp4.aarch64.rpm",
          "kernel-devel-4.19.90-2411.5.0.0305.oe2003sp4.aarch64.rpm",
          "kernel-source-4.19.90-2411.5.0.0305.oe2003sp4.aarch64.rpm",
          "kernel-tools-4.19.90-2411.5.0.0305.oe2003sp4.aarch64.rpm",
          "kernel-tools-debuginfo-4.19.90-2411.5.0.0305.oe2003sp4.aarch64.rpm",
          "kernel-tools-devel-4.19.90-2411.5.0.0305.oe2003sp4.aarch64.rpm",
          "perf-4.19.90-2411.5.0.0305.oe2003sp4.aarch64.rpm",
          "perf-debuginfo-4.19.90-2411.5.0.0305.oe2003sp4.aarch64.rpm",
          "python2-perf-4.19.90-2411.5.0.0305.oe2003sp4.aarch64.rpm",
          "python2-perf-debuginfo-4.19.90-2411.5.0.0305.oe2003sp4.aarch64.rpm",
          "python3-perf-4.19.90-2411.5.0.0305.oe2003sp4.aarch64.rpm",
          "python3-perf-debuginfo-4.19.90-2411.5.0.0305.oe2003sp4.aarch64.rpm"
        ],
        "src": [
          "kernel-4.19.90-2411.5.0.0305.oe2003sp4.src.rpm"
        ],
        "x86_64": [
          "bpftool-4.19.90-2411.5.0.0305.oe2003sp4.x86_64.rpm",
          "bpftool-debuginfo-4.19.90-2411.5.0.0305.oe2003sp4.x86_64.rpm",
          "kernel-4.19.90-2411.5.0.0305.oe2003sp4.x86_64.rpm",
          "kernel-debuginfo-4.19.90-2411.5.0.0305.oe2003sp4.x86_64.rpm",
          "kernel-debugsource-4.19.90-2411.5.0.0305.oe2003sp4.x86_64.rpm",
          "kernel-devel-4.19.90-2411.5.0.0305.oe2003sp4.x86_64.rpm",
          "kernel-source-4.19.90-2411.5.0.0305.oe2003sp4.x86_64.rpm",
          "kernel-tools-4.19.90-2411.5.0.0305.oe2003sp4.x86_64.rpm",
          "kernel-tools-debuginfo-4.19.90-2411.5.0.0305.oe2003sp4.x86_64.rpm",
          "kernel-tools-devel-4.19.90-2411.5.0.0305.oe2003sp4.x86_64.rpm",
          "perf-4.19.90-2411.5.0.0305.oe2003sp4.x86_64.rpm",
          "perf-debuginfo-4.19.90-2411.5.0.0305.oe2003sp4.x86_64.rpm",
          "python2-perf-4.19.90-2411.5.0.0305.oe2003sp4.x86_64.rpm",
          "python2-perf-debuginfo-4.19.90-2411.5.0.0305.oe2003sp4.x86_64.rpm",
          "python3-perf-4.19.90-2411.5.0.0305.oe2003sp4.x86_64.rpm",
          "python3-perf-debuginfo-4.19.90-2411.5.0.0305.oe2003sp4.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:20.03-LTS-SP4",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.19.90-2411.5.0.0305.oe2003sp4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "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:  tcp/dccp: Don\u0026apos;t use timer_pending() in reqsk_queue_unlink().  Martin KaFai Lau reported use-after-free [0] in reqsk_timer_handler().    \u0026quot;\u0026quot;\u0026quot;   We are seeing a use-after-free from a bpf prog attached to   trace_tcp_retransmit_synack. The program passes the req-\u0026gt;sk to the   bpf_sk_storage_get_tracing kernel helper which does check for null   before using it.   \u0026quot;\u0026quot;\u0026quot;  The commit 83fccfc3940c (\u0026quot;inet: fix potential deadlock in reqsk_queue_unlink()\u0026quot;) added timer_pending() in reqsk_queue_unlink() not to call del_timer_sync() from reqsk_timer_handler(), but it introduced a small race window.  Before the timer is called, expire_timers() calls detach_timer(timer, true) to clear timer-\u0026gt;entry.pprev and marks it as not pending.  If reqsk_queue_unlink() checks timer_pending() just after expire_timers() calls detach_timer(), TCP will miss del_timer_sync(); the reqsk timer will continue running and send multiple SYN+ACKs until it expires.  The reported UAF could happen if req-\u0026gt;sk is close()d earlier than the timer expiration, which is 63s by default.  The scenario would be    1. inet_csk_complete_hashdance() calls inet_csk_reqsk_queue_drop(),      but del_timer_sync() is missed    2. reqsk timer is executed and scheduled again    3. req-\u0026gt;sk is accept()ed and reqsk_put() decrements rsk_refcnt, but      reqsk timer still has another one, and inet_csk_accept() does not      clear req-\u0026gt;sk for non-TFO sockets    4. sk is close()d    5. reqsk timer is executed again, and BPF touches req-\u0026gt;sk  Let\u0026apos;s not use timer_pending() by passing the caller context to __inet_csk_reqsk_queue_drop().  Note that reqsk timer is pinned, so the issue does not happen in most use cases. [1]  [0] BUG: KFENCE: use-after-free read in bpf_sk_storage_get_tracing+0x2e/0x1b0  Use-after-free read at 0x00000000a891fb3a (in kfence-#1): bpf_sk_storage_get_tracing+0x2e/0x1b0 bpf_prog_5ea3e95db6da0438_tcp_retransmit_synack+0x1d20/0x1dda bpf_trace_run2+0x4c/0xc0 tcp_rtx_synack+0xf9/0x100 reqsk_timer_handler+0xda/0x3d0 run_timer_softirq+0x292/0x8a0 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 intel_idle_irq+0x5a/0xa0 cpuidle_enter_state+0x94/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb  kfence-#1: 0x00000000a72cc7b6-0x00000000d97616d9, size=2376, cache=TCPv6  allocated by task 0 on cpu 9 at 260507.901592s: sk_prot_alloc+0x35/0x140 sk_clone_lock+0x1f/0x3f0 inet_csk_clone_lock+0x15/0x160 tcp_create_openreq_child+0x1f/0x410 tcp_v6_syn_recv_sock+0x1da/0x700 tcp_check_req+0x1fb/0x510 tcp_v6_rcv+0x98b/0x1420 ipv6_list_rcv+0x2258/0x26e0 napi_complete_done+0x5b1/0x2990 mlx5e_napi_poll+0x2ae/0x8d0 net_rx_action+0x13e/0x590 irq_exit_rcu+0xf5/0x320 common_interrupt+0x80/0x90 asm_common_interrupt+0x22/0x40 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb  freed by task 0 on cpu 9 at 260507.927527s: rcu_core_si+0x4ff/0xf10 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb(CVE-2024-50154)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ceph: remove the incorrect Fw reference check when dirtying pages  When doing the direct-io reads it will also try to mark pages dirty, but for the read path it won\u0026apos;t hold the Fw caps and there is case will it get the Fw reference.(CVE-2024-50179)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  nilfs2: propagate directory read errors from nilfs_find_entry()  Syzbot reported that a task hang occurs in vcs_open() during a fuzzing test for nilfs2.  The root cause of this problem is that in nilfs_find_entry(), which searches for directory entries, ignores errors when loading a directory page/folio via nilfs_get_folio() fails.  If the filesystem images is corrupted, and the i_size of the directory inode is large, and the directory page/folio is successfully read but fails the sanity check, for example when it is zero-filled, nilfs_check_folio() may continue to spit out error messages in bursts.  Fix this issue by propagating the error to the callers when loading a page/folio fails in nilfs_find_entry().  The current interface of nilfs_find_entry() and its callers is outdated and cannot propagate error codes such as -EIO and -ENOMEM returned via nilfs_find_entry(), so fix it together.(CVE-2024-50202)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net: fix crash when config small gso_max_size/gso_ipv4_max_size  Config a small gso_max_size/gso_ipv4_max_size will lead to an underflow in sk_dst_gso_max_size(), which may trigger a BUG_ON crash, because sk-\u0026gt;sk_gso_max_size would be much bigger than device limits. Call Trace: tcp_write_xmit     tso_segs = tcp_init_tso_segs(skb, mss_now);         tcp_set_skb_tso_segs             tcp_skb_pcount_set                 // skb-\u0026gt;len = 524288, mss_now = 8                 // u16 tso_segs = 524288/8 = 65535 -\u0026gt; 0                 tso_segs = DIV_ROUND_UP(skb-\u0026gt;len, mss_now)     BUG_ON(!tso_segs) Add check for the minimum value of gso_max_size and gso_ipv4_max_size.(CVE-2024-50258)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  btrfs: reinitialize delayed ref list after deleting it from the list  At insert_delayed_ref() if we need to update the action of an existing ref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head\u0026apos;s ref_add_list using list_del(), which leaves the ref\u0026apos;s add_list member not reinitialized, as list_del() sets the next and prev members of the list to LIST_POISON1 and LIST_POISON2, respectively.  If later we end up calling drop_delayed_ref() against the ref, which can happen during merging or when destroying delayed refs due to a transaction abort, we can trigger a crash since at drop_delayed_ref() we call list_empty() against the ref\u0026apos;s add_list, which returns false since the list was not reinitialized after the list_del() and as a consequence we call list_del() again at drop_delayed_ref(). This results in an invalid list access since the next and prev members are set to poison pointers, resulting in a splat if CONFIG_LIST_HARDENED and CONFIG_DEBUG_LIST are set or invalid poison pointer dereferences otherwise.  So fix this by deleting from the list with list_del_init() instead.(CVE-2024-50273)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  security/keys: fix slab-out-of-bounds in key_task_permission  KASAN reports an out of bounds read: BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36 BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline] BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410 security/keys/permission.c:54 Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362  CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 Call Trace:  __dump_stack lib/dump_stack.c:82 [inline]  dump_stack+0x107/0x167 lib/dump_stack.c:123  print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400  __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560  kasan_report+0x3a/0x50 mm/kasan/report.c:585  __kuid_val include/linux/uidgid.h:36 [inline]  uid_eq include/linux/uidgid.h:63 [inline]  key_task_permission+0x394/0x410 security/keys/permission.c:54  search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793  This issue was also reported by syzbot.  It can be reproduced by following these steps(more details [1]): 1. Obtain more than 32 inputs that have similar hashes, which ends with the    pattern \u0026apos;0xxxxxxxe6\u0026apos;. 2. Reboot and add the keys obtained in step 1.  The reproducer demonstrates how this issue happened: 1. In the search_nested_keyrings function, when it iterates through the    slots in a node(below tag ascend_to_node), if the slot pointer is meta    and node-\u0026gt;back_pointer != NULL(it means a root), it will proceed to    descend_to_node. However, there is an exception. If node is the root,    and one of the slots points to a shortcut, it will be treated as a    keyring. 2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function.    However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as    ASSOC_ARRAY_PTR_SUBTYPE_MASK. 3. When 32 keys with the similar hashes are added to the tree, the ROOT    has keys with hashes that are not similar (e.g. slot 0) and it splits    NODE A without using a shortcut. When NODE A is filled with keys that    all hashes are xxe6, the keys are similar, NODE A will split with a    shortcut. Finally, it forms the tree as shown below, where slot 6 points    to a shortcut.                        NODE A               +------\u0026gt;+---+       ROOT    |       | 0 | xxe6       +---+   |       +---+  xxxx | 0 | shortcut  :   : xxe6       +---+   |       +---+  xxe6 :   :   |       |   | xxe6       +---+   |       +---+       | 6 |---+       :   : xxe6       +---+           +---+  xxe6 :   :           | f | xxe6       +---+           +---+  xxe6 | f |       +---+  4. As mentioned above, If a slot(slot 6) of the root points to a shortcut,    it may be mistakenly transferred to a key*, leading to a read    out-of-bounds read.  To fix this issue, one should jump to descend_to_node if the ptr is a shortcut, regardless of whether the node is root or not.  [1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/  [jarkko: tweaked the commit message a bit to have an appropriate closes  tag.](CVE-2024-50301)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  media: s5p-jpeg: prevent buffer overflows  The current logic allows word to be less than 2. If this happens, there will be buffer overflows, as reported by smatch. Add extra checks to prevent it.  While here, remove an unused word = 0 assignment.(CVE-2024-53061)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  nfs: Fix KMSAN warning in decode_getfattr_attrs()  Fix the following KMSAN warning:  CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G    B Tainted: [B]=BAD_PAGE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) ===================================================== ===================================================== BUG: KMSAN: uninit-value in decode_getfattr_attrs+0x2d6d/0x2f90  decode_getfattr_attrs+0x2d6d/0x2f90  decode_getfattr_generic+0x806/0xb00  nfs4_xdr_dec_getattr+0x1de/0x240  rpcauth_unwrap_resp_decode+0xab/0x100  rpcauth_unwrap_resp+0x95/0xc0  call_decode+0x4ff/0xb50  __rpc_execute+0x57b/0x19d0  rpc_execute+0x368/0x5e0  rpc_run_task+0xcfe/0xee0  nfs4_proc_getattr+0x5b5/0x990  __nfs_revalidate_inode+0x477/0xd00  nfs_access_get_cached+0x1021/0x1cc0  nfs_do_access+0x9f/0xae0  nfs_permission+0x1e4/0x8c0  inode_permission+0x356/0x6c0  link_path_walk+0x958/0x1330  path_lookupat+0xce/0x6b0  filename_lookup+0x23e/0x770  vfs_statx+0xe7/0x970  vfs_fstatat+0x1f2/0x2c0  __se_sys_newfstatat+0x67/0x880  __x64_sys_newfstatat+0xbd/0x120  x64_sys_call+0x1826/0x3cf0  do_syscall_64+0xd0/0x1b0  entry_SYSCALL_64_after_hwframe+0x77/0x7f  The KMSAN warning is triggered in decode_getfattr_attrs(), when calling decode_attr_mdsthreshold(). It appears that fattr-\u0026gt;mdsthreshold is not initialized.  Fix the issue by initializing fattr-\u0026gt;mdsthreshold to NULL in nfs_fattr_init().(CVE-2024-53066)",
  "id": "OESA-2024-2495",
  "modified": "2026-08-06T11:07:58Z",
  "published": "2024-11-29T11:07:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2495"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50154"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50179"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50202"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50258"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50273"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50301"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53061"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53066"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2024-50154",
    "CVE-2024-50179",
    "CVE-2024-50202",
    "CVE-2024-50258",
    "CVE-2024-50273",
    "CVE-2024-50301",
    "CVE-2024-53061",
    "CVE-2024-53066"
  ]
}