{
  "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-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm",
          "bpftool-debuginfo-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm",
          "kernel-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm",
          "kernel-debuginfo-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm",
          "kernel-debugsource-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm",
          "kernel-devel-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm",
          "kernel-headers-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm",
          "kernel-source-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm",
          "kernel-tools-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm",
          "kernel-tools-debuginfo-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm",
          "kernel-tools-devel-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm",
          "perf-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm",
          "perf-debuginfo-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm",
          "python3-perf-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm",
          "python3-perf-debuginfo-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm"
        ],
        "src": [
          "kernel-6.6.0-129.0.0.127.oe2403sp1.src.rpm"
        ],
        "x86_64": [
          "bpftool-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm",
          "bpftool-debuginfo-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm",
          "kernel-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm",
          "kernel-debuginfo-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm",
          "kernel-debugsource-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm",
          "kernel-devel-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm",
          "kernel-headers-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm",
          "kernel-source-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm",
          "kernel-tools-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm",
          "kernel-tools-debuginfo-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm",
          "kernel-tools-devel-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm",
          "perf-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm",
          "perf-debuginfo-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm",
          "python3-perf-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm",
          "python3-perf-debuginfo-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:24.03-LTS-SP1",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS-SP1"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.6.0-129.0.0.127.oe2403sp1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:usb: musb: sunxi: Fix accessing an released usb phyCommit 6ed05c68cbca ( usb: musb: sunxi: Explicitly release USB PHY onexit ) 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;xceivsunxi_musb_probe() -\u0026gt; devm_usb_get_phy().2) register and unregister platform driver @musb_drivermusb_probe() -\u0026gt; sunxi_musb_init()use the phy here//the phy is released heremusb_remove() -\u0026gt; sunxi_musb_exit() -\u0026gt; devm_usb_put_phy()3) register @musb_driver againmusb_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)\n\nIn the Linux kernel, the following vulnerability has been resolved:dm cache: fix out-of-bounds access to the dirty bitset when resizingdm-cache checks the dirty bits of the cache blocks to be dropped whenshrinking the fast device, but an index bug in bitset iteration causesout-of-bounds access.Reproduce steps:1. create a cache device of 1024 cache blocks (128 bytes dirty bitset)dmsetup create cmeta --table  0 8192 linear /dev/sdc 0 dmsetup create cdata --table  0 131072 linear /dev/sdc 8192 dmsetup create corig --table  0 524288 linear /dev/sdc 262144 dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=directdmsetup create cache --table  0 524288 cache /dev/mapper/cmeta  /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0 2. shrink the fast device to 512 cache blocks, triggering out-of-bounds   access to the dirty bitset (offset 0x80)dmsetup suspend cachedmsetup reload cdata --table  0 65536 linear /dev/sdc 8192 dmsetup resume cdatadmsetup resume cacheKASAN reports:  BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0  Read of size 8 at addr ffffc900000f3080 by task dmsetup/131  (...snip...)  The buggy address belongs to the virtual mapping at   [ffffc900000f3000, ffffc900000f5000) created by:   cache_ctr+0x176a/0x35f0  (...snip...)  Memory state around the buggy address:   ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8   ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  \u0026gt;ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8                     ^   ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8   ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8Fix by making the index post-incremented.(CVE-2024-50279)\n\nIn the Linux kernel, the following vulnerability has been resolved:iio: gts-helper: Fix memory leaks for the error path of iio_gts_build_avail_scale_table()If per_time_scales[i] or per_time_gains[i] kcalloc fails in the for loopof iio_gts_build_avail_scale_table(), the err_free_out will fail to callkfree() each time when i is reduced to 0, so all the per_time_scales[0]and per_time_gains[0] will not be freed, which will cause memory leaks.Fix it by checking if i \u0026gt;= 0.(CVE-2024-53076)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath10k: avoid NULL pointer error during sdio remove\n\nWhen running \u0026apos;rmmod ath10k\u0026apos;, ath10k_sdio_remove() will free sdio\nworkqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ON\nis set to yes, kernel panic will happen:\nCall trace:\n destroy_workqueue+0x1c/0x258\n ath10k_sdio_remove+0x84/0x94\n sdio_bus_remove+0x50/0x16c\n device_release_driver_internal+0x188/0x25c\n device_driver_detach+0x20/0x2c\n\nThis is because during \u0026apos;rmmod ath10k\u0026apos;, ath10k_sdio_remove() will call\nath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release()\nwill finally be called in ath10k_core_destroy(). This function will free\nstruct cfg80211_registered_device *rdev and all its members, including\nwiphy, dev and the pointer of sdio workqueue. Then the pointer of sdio\nworkqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON.\n\nAfter device release, destroy_workqueue() will use NULL pointer then the\nkernel panic happen.\n\nCall trace:\nath10k_sdio_remove\n  -\u0026gt;ath10k_core_unregister\n    \u2026\u2026\n    -\u0026gt;ath10k_core_stop\n      -\u0026gt;ath10k_hif_stop\n        -\u0026gt;ath10k_sdio_irq_disable\n    -\u0026gt;ath10k_hif_power_down\n      -\u0026gt;del_timer_sync(\u0026amp;ar_sdio-\u0026gt;sleep_timer)\n  -\u0026gt;ath10k_core_destroy\n    -\u0026gt;ath10k_mac_destroy\n      -\u0026gt;ieee80211_free_hw\n        -\u0026gt;wiphy_free\n    \u2026\u2026\n          -\u0026gt;wiphy_dev_release\n  -\u0026gt;destroy_workqueue\n\nNeed to call destroy_workqueue() before ath10k_core_destroy(), free\nthe work queue buffer first and then free pointer of work queue by\nath10k_core_destroy(). This order matches the error path order in\nath10k_sdio_probe().\n\nNo work will be queued on sdio workqueue between it is destroyed and\nath10k_core_destroy() is called. Based on the call_stack above, the\nreason is:\nOnly ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() and\nath10k_sdio_irq_disable() will queue work on sdio workqueue.\nSleep timer will be deleted before ath10k_core_destroy() in\nath10k_hif_power_down().\nath10k_sdio_irq_disable() only be called in ath10k_hif_stop().\nath10k_core_unregister() will call ath10k_hif_power_down() to stop hif\nbus, so ath10k_sdio_hif_tx_sg() won\u0026apos;t be called anymore.\n\nTested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189(CVE-2024-56599)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: iwlwifi: limit printed string from FW file\n\nThere\u0026apos;s no guarantee here that the file is always with a\nNUL-termination, so reading the string may read beyond the\nend of the TLV. If that\u0026apos;s the last TLV in the file, it can\nperhaps even read beyond the end of the file buffer.\n\nFix that by limiting the print format to the size of the\nbuffer we have.(CVE-2025-21905)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nppp: Fix KMSAN uninit-value warning with bpf\n\nSyzbot caught an \u0026quot;KMSAN: uninit-value\u0026quot; warning [1], which is caused by the\nppp driver not initializing a 2-byte header when using socket filter.\n\nThe following code can generate a PPP filter BPF program:\n\u0026apos;\u0026apos;\u0026apos;\nstruct bpf_program fp;\npcap_t *handle;\nhandle = pcap_open_dead(DLT_PPP_PPPD, 65535);\npcap_compile(handle, \u0026amp;fp, \u0026quot;ip and outbound\u0026quot;, 0, 0);\nbpf_dump(\u0026amp;fp, 1);\n\u0026apos;\u0026apos;\u0026apos;\nIts output is:\n\u0026apos;\u0026apos;\u0026apos;\n(000) ldh [2]\n(001) jeq #0x21 jt 2 jf 5\n(002) ldb [0]\n(003) jeq #0x1 jt 4 jf 5\n(004) ret #65535\n(005) ret #0\n\u0026apos;\u0026apos;\u0026apos;\nWen can find similar code at the following link:\nhttps://github.com/ppp-project/ppp/blob/master/pppd/options.c#L1680\nThe maintainer of this code repository is also the original maintainer\nof the ppp driver.\n\nAs you can see the BPF program skips 2 bytes of data and then reads the\n\u0026apos;Protocol\u0026apos; field to determine if it\u0026apos;s an IP packet. Then it read the first\nbyte of the first 2 bytes to determine the direction.\n\nThe issue is that only the first byte indicating direction is initialized\nin current ppp driver code while the second byte is not initialized.\n\nFor normal BPF programs generated by libpcap, uninitialized data won\u0026apos;t be\nused, so it\u0026apos;s not a problem. However, for carefully crafted BPF programs,\nsuch as those generated by syzkaller [2], which start reading from offset\n0, the uninitialized data will be used and caught by KMSAN.\n\n[1] https://syzkaller.appspot.com/bug?extid=853242d9c9917165d791\n[2] https://syzkaller.appspot.com/text?tag=ReproC\u0026amp;x=11994913980000(CVE-2025-21922)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: venus: hfi: add check to handle incorrect queue size\n\nqsize represents size of shared queued between driver and video\nfirmware. Firmware can modify this value to an invalid large value. In\nsuch situation, empty_space will be bigger than the space actually\navailable. Since new_wr_idx is not checked, so the following code will\nresult in an OOB write.\n...\nqsize = qhdr-\u0026gt;q_size\n\nif (wr_idx \u0026gt;= rd_idx)\n empty_space = qsize - (wr_idx - rd_idx)\n....\nif (new_wr_idx \u0026lt; qsize) {\n memcpy(wr_ptr, packet, dwords \u0026lt;\u0026lt; 2) --\u0026gt; OOB write\n\nAdd check to ensure qsize is within the allocated size while\nreading and writing packets into the queue.(CVE-2025-23158)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: mediatek: vcodec: Fix a resource leak related to the scp device in FW initialization\n\nOn Mediatek devices with a system companion processor (SCP) the mtk_scp\nstructure has to be removed explicitly to avoid a resource leak.\nFree the structure in case the allocation of the firmware structure fails\nduring the firmware initialization.(CVE-2025-23160)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: tls: explicitly disallow disconnect\n\nsyzbot discovered that it can disconnect a TLS socket and then\nrun into all sort of unexpected corner cases. I have a vague\nrecollection of Eric pointing this out to us a long time ago.\nSupporting disconnect is really hard, for one thing if offload\nis enabled we\u0026apos;d need to wait for all packets to be _acked_.\nDisconnect is not commonly used, disallow it.\n\nThe immediate problem syzbot run into is the warning in the strp,\nbut that\u0026apos;s just the easiest bug to trigger:\n\n  WARNING: CPU: 0 PID: 5834 at net/tls/tls_strp.c:486 tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486\n  RIP: 0010:tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   tls_rx_rec_wait+0x280/0xa60 net/tls/tls_sw.c:1363\n   tls_sw_recvmsg+0x85c/0x1c30 net/tls/tls_sw.c:2043\n   inet6_recvmsg+0x2c9/0x730 net/ipv6/af_inet6.c:678\n   sock_recvmsg_nosec net/socket.c:1023 [inline]\n   sock_recvmsg+0x109/0x280 net/socket.c:1045\n   __sys_recvfrom+0x202/0x380 net/socket.c:2237(CVE-2025-37756)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix the warning from __kernel_write_iter\n\n[ 2110.972290] ------------[ cut here ]------------\n[ 2110.972301] WARNING: CPU: 3 PID: 735 at fs/read_write.c:599 __kernel_write_iter+0x21b/0x280\n\nThis patch doesn\u0026apos;t allow writing to directory.(CVE-2025-37775)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix use-after-free in smb_break_all_levII_oplock()\n\nThere is a room in smb_break_all_levII_oplock that can cause racy issues\nwhen unlocking in the middle of the loop. This patch use read lock\nto protect whole loop.(CVE-2025-37776)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npwm: mediatek: Prevent divide-by-zero in pwm_mediatek_config()\n\nWith CONFIG_COMPILE_TEST \u0026amp;\u0026amp; !CONFIG_HAVE_CLK, pwm_mediatek_config() has a\ndivide-by-zero in the following line:\n\n\tdo_div(resolution, clk_get_rate(pc-\u0026gt;clk_pwms[pwm-\u0026gt;hwpwm]));\n\ndue to the fact that the !CONFIG_HAVE_CLK version of clk_get_rate()\nreturns zero.\n\nThis is presumably just a theoretical problem: COMPILE_TEST overrides\nthe dependency on RALINK which would select COMMON_CLK.  Regardless it\u0026apos;s\na good idea to check for the error explicitly to avoid divide-by-zero.\n\nFixes the following warning:\n\n  drivers/pwm/pwm-mediatek.o: warning: objtool: .text: unexpected end of section\n\n[ukleinek: s/CONFIG_CLK/CONFIG_HAVE_CLK/](CVE-2025-37850)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/amd: Fix potential buffer overflow in parse_ivrs_acpihid\n\nThere is a string parsing logic error which can lead to an overflow of hid\nor uid buffers. Comparing ACPIID_LEN against a total string length doesn\u0026apos;t\ntake into account the lengths of individual hid and uid buffers so the\ncheck is insufficient in some cases. For example if the length of hid\nstring is 4 and the length of the uid string is 260, the length of str\nwill be equal to ACPIID_LEN + 1 but uid string will overflow uid buffer\nwhich size is 256.\n\nThe same applies to the hid string with length 13 and uid string with\nlength 250.\n\nCheck the length of hid and uid strings separately to prevent\nbuffer overflow.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37927)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/sev: Evict cache lines during SNP memory validation\n\nAn SNP cache coherency vulnerability requires a cache line eviction\nmitigation when validating memory after a page state change to private.\nThe specific mitigation is to touch the first and last byte of each 4K\npage that is being validated. There is no need to perform the mitigation\nwhen performing a page state change to shared and rescinding validation.\n\nCPUID bit Fn8000001F_EBX[31] defines the COHERENCY_SFW_NO CPUID bit\nthat, when set, indicates that the software mitigation for this\nvulnerability is not needed.\n\nImplement the mitigation and invoke it when validating memory (making it\nprivate) and the COHERENCY_SFW_NO bit is not set, indicating the SNP\nguest is vulnerable.(CVE-2025-38560)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: remove read access to debugfs files\n\nThe \u0026apos;command\u0026apos; and \u0026apos;netdev_ops\u0026apos; debugfs files are a legacy debugging\ninterface supported by the i40e driver since its early days by commit\n02e9c290814c (\u0026quot;i40e: debugfs interface\u0026quot;).\n\nBoth of these debugfs files provide a read handler which is mostly useless,\nand which is implemented with questionable logic. They both use a static\n256 byte buffer which is initialized to the empty string. In the case of\nthe \u0026apos;command\u0026apos; file this buffer is literally never used and simply wastes\nspace. In the case of the \u0026apos;netdev_ops\u0026apos; file, the last command written is\nsaved here.\n\nOn read, the files contents are presented as the name of the device\nfollowed by a colon and then the contents of their respective static\nbuffer. For \u0026apos;command\u0026apos; this will always be \u0026quot;\u0026lt;device\u0026gt;: \u0026quot;. For \u0026apos;netdev_ops\u0026apos;,\nthis will be \u0026quot;\u0026lt;device\u0026gt;: \u0026lt;last command written\u0026gt;\u0026quot;. But note the buffer is\nshared between all devices operated by this module. At best, it is mostly\nmeaningless information, and at worse it could be accessed simultaneously\nas there doesn\u0026apos;t appear to be any locking mechanism.\n\nWe have also recently received multiple reports for both read functions\nabout their use of snprintf and potential overflow that could result in\nreading arbitrary kernel memory. For the \u0026apos;command\u0026apos; file, this is definitely\nimpossible, since the static buffer is always zero and never written to.\nFor the \u0026apos;netdev_ops\u0026apos; file, it does appear to be possible, if the user\ncarefully crafts the command input, it will be copied into the buffer,\nwhich could be large enough to cause snprintf to truncate, which then\ncauses the copy_to_user to read beyond the length of the buffer allocated\nby kzalloc.\n\nA minimal fix would be to replace snprintf() with scnprintf() which would\ncap the return to the number of bytes written, preventing an overflow. A\nmore involved fix would be to drop the mostly useless static buffers,\nsaving 512 bytes and modifying the read functions to stop needing those as\ninput.\n\nInstead, lets just completely drop the read access to these files. These\nare debug interfaces exposed as part of debugfs, and I don\u0026apos;t believe that\ndropping read access will break any script, as the provided output is\npretty useless. You can find the netdev name through other more standard\ninterfaces, and the \u0026apos;netdev_ops\u0026apos; interface can easily result in garbage if\nyou issue simultaneous writes to multiple devices at once.\n\nIn order to properly remove the i40e_dbg_netdev_ops_buf, we need to\nrefactor its write function to avoid using the static buffer. Instead, use\nthe same logic as the i40e_dbg_command_write, with an allocated buffer.\nUpdate the code to use this instead of the static buffer, and ensure we\nfree the buffer on exit. This fixes simultaneous writes to \u0026apos;netdev_ops\u0026apos; on\nmultiple devices, and allows us to remove the now unused static buffer\nalong with removing the read access.(CVE-2025-39901)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: smbdirect: verify remaining_data_length respects max_fragmented_recv_size\n\nThis is inspired by the check for data_offset + data_length.(CVE-2025-39942)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/ksm: fix flag-dropping behavior in ksm_madvise\n\nsyzkaller discovered the following crash: (kernel BUG)\n\n[   44.607039] ------------[ cut here ]------------\n[   44.607422] kernel BUG at mm/userfaultfd.c:2067!\n[   44.608148] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI\n[   44.608814] CPU: 1 UID: 0 PID: 2475 Comm: reproducer Not tainted 6.16.0-rc6 #1 PREEMPT(none)\n[   44.609635] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\n[   44.610695] RIP: 0010:userfaultfd_release_all+0x3a8/0x460\n\n\u0026lt;snip other registers, drop unreliable trace\u0026gt;\n\n[   44.617726] Call Trace:\n[   44.617926]  \u0026lt;TASK\u0026gt;\n[   44.619284]  userfaultfd_release+0xef/0x1b0\n[   44.620976]  __fput+0x3f9/0xb60\n[   44.621240]  fput_close_sync+0x110/0x210\n[   44.622222]  __x64_sys_close+0x8f/0x120\n[   44.622530]  do_syscall_64+0x5b/0x2f0\n[   44.622840]  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[   44.623244] RIP: 0033:0x7f365bb3f227\n\nKernel panics because it detects UFFD inconsistency during\nuserfaultfd_release_all().  Specifically, a VMA which has a valid pointer\nto vma-\u0026gt;vm_userfaultfd_ctx, but no UFFD flags in vma-\u0026gt;vm_flags.\n\nThe inconsistency is caused in ksm_madvise(): when user calls madvise()\nwith MADV_UNMEARGEABLE on a VMA that is registered for UFFD in MINOR mode,\nit accidentally clears all flags stored in the upper 32 bits of\nvma-\u0026gt;vm_flags.\n\nAssuming x86_64 kernel build, unsigned long is 64-bit and unsigned int and\nint are 32-bit wide.  This setup causes the following mishap during the \u0026amp;=\n~VM_MERGEABLE assignment.\n\nVM_MERGEABLE is a 32-bit constant of type unsigned int, 0x8000\u0026apos;0000. \nAfter ~ is applied, it becomes 0x7fff\u0026apos;ffff unsigned int, which is then\npromoted to unsigned long before the \u0026amp; operation.  This promotion fills\nupper 32 bits with leading 0s, as we\u0026apos;re doing unsigned conversion (and\neven for a signed conversion, this wouldn\u0026apos;t help as the leading bit is 0).\n\u0026amp; operation thus ends up AND-ing vm_flags with 0x0000\u0026apos;0000\u0026apos;7fff\u0026apos;ffff\ninstead of intended 0xffff\u0026apos;ffff\u0026apos;7fff\u0026apos;ffff and hence accidentally clears\nthe upper 32-bits of its value.\n\nFix it by changing `VM_MERGEABLE` constant to unsigned long, using the\nBIT() macro.\n\nNote: other VM_* flags are not affected: This only happens to the\nVM_MERGEABLE flag, as the other VM_* flags are all constants of type int\nand after ~ operation, they end up with leading 1 and are thus converted\nto unsigned long with leading 1s.\n\nNote 2:\nAfter commit 31defc3b01d9 (\u0026quot;userfaultfd: remove (VM_)BUG_ON()s\u0026quot;), this is\nno longer a kernel BUG, but a WARNING at the same place:\n\n[   45.595973] WARNING: CPU: 1 PID: 2474 at mm/userfaultfd.c:2067\n\nbut the root-cause (flag-drop) remains the same.\n\n[(CVE-2025-40040)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: use dst_dev_rcu() in sk_setup_caps()\n\nUse RCU to protect accesses to dst-\u0026gt;dev from sk_setup_caps()\nand sk_dst_gso_max_size().\n\nAlso use dst_dev_rcu() in ip6_dst_mtu_maybe_forward(),\nand ip_dst_mtu_maybe_forward().\n\nip4_dst_hoplimit() can use dst_dev_net_rcu().(CVE-2025-40170)",
  "id": "OESA-2025-2883",
  "modified": "2026-08-06T11:10:01Z",
  "published": "2025-12-30T11:10:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2883"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50269"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50279"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53076"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56599"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21905"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21922"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23158"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23160"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37756"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37775"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37776"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37850"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37927"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38560"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39901"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39942"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40040"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40170"
    }
  ],
  "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-50269",
    "CVE-2024-50279",
    "CVE-2024-53076",
    "CVE-2024-56599",
    "CVE-2025-21905",
    "CVE-2025-21922",
    "CVE-2025-23158",
    "CVE-2025-23160",
    "CVE-2025-37756",
    "CVE-2025-37775",
    "CVE-2025-37776",
    "CVE-2025-37850",
    "CVE-2025-37927",
    "CVE-2025-38560",
    "CVE-2025-39901",
    "CVE-2025-39942",
    "CVE-2025-40040",
    "CVE-2025-40170"
  ]
}