{"schema_version":"1.7.2","id":"OESA-2025-1081","modified":"2025-01-24T13:41:31Z","published":"2025-01-24T13:41:31Z","upstream":["CVE-2024-24858","CVE-2024-26602","CVE-2024-26820","CVE-2024-26857","CVE-2024-26956","CVE-2024-26966","CVE-2024-26969","CVE-2024-26974","CVE-2024-26981","CVE-2024-27001","CVE-2024-38547","CVE-2024-38621","CVE-2024-44969","CVE-2024-50279","CVE-2024-53050","CVE-2024-53226","CVE-2024-56549","CVE-2024-56626","CVE-2024-56648","CVE-2024-56690","CVE-2024-56728","CVE-2024-56758"],"summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nA race condition was found in the Linux kernel\u0026apos;s net/bluetooth in {conn,adv}_{min,max}_interval_set() function. This can result in I2cap connection or broadcast abnormality issue, possibly leading to denial of service.\n\n\n\n\n(CVE-2024-24858)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched/membarrier: reduce the ability to hammer on sys_membarrier\n\nOn some systems, sys_membarrier can be very expensive, causing overall\nslowdowns for everything.  So put a lock on the path in order to\nserialize the accesses to prevent the ability for this to be called at\ntoo high of a frequency and saturate the machine.(CVE-2024-26602)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhv_netvsc: Register VF in netvsc_probe if NET_DEVICE_REGISTER missed\n\nIf hv_netvsc driver is unloaded and reloaded, the NET_DEVICE_REGISTER\nhandler cannot perform VF register successfully as the register call\nis received before netvsc_probe is finished. This is because we\nregister register_netdevice_notifier() very early( even before\nvmbus_driver_register()).\nTo fix this, we try to register each such matching VF( if it is visible\nas a netdevice) at the end of netvsc_probe.(CVE-2024-26820)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngeneve: make sure to pull inner header in geneve_rx()\n\nsyzbot triggered a bug in geneve_rx() [1]\n\nIssue is similar to the one I fixed in commit 8d975c15c0cd\n(\u0026quot;ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()\u0026quot;)\n\nWe have to save skb-\u0026gt;network_header in a temporary variable\nin order to be able to recompute the network_header pointer\nafter a pskb_inet_may_pull() call.\n\npskb_inet_may_pull() makes sure the needed headers are in skb-\u0026gt;head.\n\n[1]\nBUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]\n BUG: KMSAN: uninit-value in geneve_rx drivers/net/geneve.c:279 [inline]\n BUG: KMSAN: uninit-value in geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391\n  IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]\n  geneve_rx drivers/net/geneve.c:279 [inline]\n  geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391\n  udp_queue_rcv_one_skb+0x1d39/0x1f20 net/ipv4/udp.c:2108\n  udp_queue_rcv_skb+0x6ae/0x6e0 net/ipv4/udp.c:2186\n  udp_unicast_rcv_skb+0x184/0x4b0 net/ipv4/udp.c:2346\n  __udp4_lib_rcv+0x1c6b/0x3010 net/ipv4/udp.c:2422\n  udp_rcv+0x7d/0xa0 net/ipv4/udp.c:2604\n  ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205\n  ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233\n  NF_HOOK include/linux/netfilter.h:314 [inline]\n  ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254\n  dst_input include/net/dst.h:461 [inline]\n  ip_rcv_finish net/ipv4/ip_input.c:449 [inline]\n  NF_HOOK include/linux/netfilter.h:314 [inline]\n  ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569\n  __netif_receive_skb_one_core net/core/dev.c:5534 [inline]\n  __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648\n  process_backlog+0x480/0x8b0 net/core/dev.c:5976\n  __napi_poll+0xe3/0x980 net/core/dev.c:6576\n  napi_poll net/core/dev.c:6645 [inline]\n  net_rx_action+0x8b8/0x1870 net/core/dev.c:6778\n  __do_softirq+0x1b7/0x7c5 kernel/softirq.c:553\n  do_softirq+0x9a/0xf0 kernel/softirq.c:454\n  __local_bh_enable_ip+0x9b/0xa0 kernel/softirq.c:381\n  local_bh_enable include/linux/bottom_half.h:33 [inline]\n  rcu_read_unlock_bh include/linux/rcupdate.h:820 [inline]\n  __dev_queue_xmit+0x2768/0x51c0 net/core/dev.c:4378\n  dev_queue_xmit include/linux/netdevice.h:3171 [inline]\n  packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276\n  packet_snd net/packet/af_packet.c:3081 [inline]\n  packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113\n  sock_sendmsg_nosec net/socket.c:730 [inline]\n  __sock_sendmsg net/socket.c:745 [inline]\n  __sys_sendto+0x735/0xa10 net/socket.c:2191\n  __do_sys_sendto net/socket.c:2203 [inline]\n  __se_sys_sendto net/socket.c:2199 [inline]\n  __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\n\nUninit was created at:\n  slab_post_alloc_hook mm/slub.c:3819 [inline]\n  slab_alloc_node mm/slub.c:3860 [inline]\n  kmem_cache_alloc_node+0x5cb/0xbc0 mm/slub.c:3903\n  kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560\n  __alloc_skb+0x352/0x790 net/core/skbuff.c:651\n  alloc_skb include/linux/skbuff.h:1296 [inline]\n  alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6394\n  sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2783\n  packet_alloc_skb net/packet/af_packet.c:2930 [inline]\n  packet_snd net/packet/af_packet.c:3024 [inline]\n  packet_sendmsg+0x70c2/0x9f10 net/packet/af_packet.c:3113\n  sock_sendmsg_nosec net/socket.c:730 [inline]\n  __sock_sendmsg net/socket.c:745 [inline]\n  __sys_sendto+0x735/0xa10 net/socket.c:2191\n  __do_sys_sendto net/socket.c:2203 [inline]\n  __se_sys_sendto net/socket.c:2199 [inline]\n  __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b(CVE-2024-26857)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix failure to detect DAT corruption in btree and direct mappings\n\nPatch series \u0026quot;nilfs2: fix kernel bug at submit_bh_wbc()\u0026quot;.\n\nThis resolves a kernel BUG reported by syzbot.  Since there are two\nflaws involved, I\u0026apos;ve made each one a separate patch.\n\nThe first patch alone resolves the syzbot-reported bug, but I think\nboth fixes should be sent to stable, so I\u0026apos;ve tagged them as such.\n\n\nThis patch (of 2):\n\nSyzbot has reported a kernel bug in submit_bh_wbc() when writing file data\nto a nilfs2 file system whose metadata is corrupted.\n\nThere are two flaws involved in this issue.\n\nThe first flaw is that when nilfs_get_block() locates a data block using\nbtree or direct mapping, if the disk address translation routine\nnilfs_dat_translate() fails with internal code -ENOENT due to DAT metadata\ncorruption, it can be passed back to nilfs_get_block().  This causes\nnilfs_get_block() to misidentify an existing block as non-existent,\ncausing both data block lookup and insertion to fail inconsistently.\n\nThe second flaw is that nilfs_get_block() returns a successful status in\nthis inconsistent state.  This causes the caller __block_write_begin_int()\nor others to request a read even though the buffer is not mapped,\nresulting in a BUG_ON check for the BH_Mapped flag in submit_bh_wbc()\nfailing.\n\nThis fixes the first issue by changing the return value to code -EINVAL\nwhen a conversion using DAT fails with code -ENOENT, avoiding the\nconflicting condition that leads to the kernel bug described above.  Here,\ncode -EINVAL indicates that metadata corruption was detected during the\nblock lookup, which will be properly handled as a file system error and\nconverted to -EIO when passing through the nilfs2 bmap layer.(CVE-2024-26956)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nclk: qcom: mmcc-apq8084: fix terminating of frequency table arrays\n\nThe frequency table arrays are supposed to be terminated with an\nempty element. Add such entry to the end of the arrays where it\nis missing in order to avoid possible out-of-bound access when\nthe table is traversed by functions like qcom_find_freq() or\nqcom_find_freq_floor().\n\nOnly compile tested.(CVE-2024-26966)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nclk: qcom: gcc-ipq8074: fix terminating of frequency table arrays\n\nThe frequency table arrays are supposed to be terminated with an\nempty element. Add such entry to the end of the arrays where it\nis missing in order to avoid possible out-of-bound access when\nthe table is traversed by functions like qcom_find_freq() or\nqcom_find_freq_floor().\n\nOnly compile tested.(CVE-2024-26969)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: qat - resolve race condition during AER recovery\n\nDuring the PCI AER system\u0026apos;s error recovery process, the kernel driver\nmay encounter a race condition with freeing the reset_data structure\u0026apos;s\nmemory. If the device restart will take more than 10 seconds the function\nscheduling that restart will exit due to a timeout, and the reset_data\nstructure will be freed. However, this data structure is used for\ncompletion notification after the restart is completed, which leads\nto a UAF bug.\n\nThis results in a KFENCE bug notice.\n\n  BUG: KFENCE: use-after-free read in adf_device_reset_worker+0x38/0xa0 [intel_qat]\n  Use-after-free read at 0x00000000bc56fddf (in kfence-#142):\n  adf_device_reset_worker+0x38/0xa0 [intel_qat]\n  process_one_work+0x173/0x340\n\nTo resolve this race condition, the memory associated to the container\nof the work_struct is freed on the worker if the timeout expired,\notherwise on the function that schedules the worker.\nThe timeout detection can be done by checking if the caller is\nstill waiting for completion or not by using completion_done() function.(CVE-2024-26974)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix OOB in nilfs_set_de_type\n\nThe size of the nilfs_type_by_mode array in the fs/nilfs2/dir.c file is\ndefined as \u0026quot;S_IFMT \u0026gt;\u0026gt; S_SHIFT\u0026quot;, but the nilfs_set_de_type() function,\nwhich uses this array, specifies the index to read from the array in the\nsame way as \u0026quot;(mode \u0026amp; S_IFMT) \u0026gt;\u0026gt; S_SHIFT\u0026quot;.\n\nstatic void nilfs_set_de_type(struct nilfs_dir_entry *de, struct inode\n *inode)\n{\n\tumode_t mode = inode-\u0026gt;i_mode;\n\n\tde-\u0026gt;file_type = nilfs_type_by_mode[(mode \u0026amp; S_IFMT)\u0026gt;\u0026gt;S_SHIFT]; // oob\n}\n\nHowever, when the index is determined this way, an out-of-bounds (OOB)\nerror occurs by referring to an index that is 1 larger than the array size\nwhen the condition \u0026quot;mode \u0026amp; S_IFMT == S_IFMT\u0026quot; is satisfied.  Therefore, a\npatch to resize the nilfs_type_by_mode array should be applied to prevent\nOOB errors.(CVE-2024-26981)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncomedi: vmk80xx: fix incomplete endpoint checking\n\nWhile vmk80xx does have endpoint checking implemented, some things\ncan fall through the cracks. Depending on the hardware model,\nURBs can have either bulk or interrupt type, and current version\nof vmk80xx_find_usb_endpoints() function does not take that fully\ninto account. While this warning does not seem to be too harmful,\nat the very least it will crash systems with \u0026apos;panic_on_warn\u0026apos; set on\nthem.\n\nFix the issue found by Syzkaller [1] by somewhat simplifying the\nendpoint checking process with usb_find_common_endpoints() and\nensuring that only expected endpoint types are present.\n\nThis patch has not been tested on real hardware.\n\n[1] Syzkaller report:\nusb 1-1: BOGUS urb xfer, pipe 1 != type 3\nWARNING: CPU: 0 PID: 781 at drivers/usb/core/urb.c:504 usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n usb_start_wait_urb+0x113/0x520 drivers/usb/core/message.c:59\n vmk80xx_reset_device drivers/comedi/drivers/vmk80xx.c:227 [inline]\n vmk80xx_auto_attach+0xa1c/0x1a40 drivers/comedi/drivers/vmk80xx.c:818\n comedi_auto_config+0x238/0x380 drivers/comedi/drivers.c:1067\n usb_probe_interface+0x5cd/0xb00 drivers/usb/core/driver.c:399\n...\n\nSimilar issue also found by Syzkaller:(CVE-2024-27001)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: atomisp: ssh_css: Fix a null-pointer dereference in load_video_binaries\n\nThe allocation failure of mycs-\u0026gt;yuv_scaler_binary in load_video_binaries()\nis followed with a dereference of mycs-\u0026gt;yuv_scaler_binary after the\nfollowing call chain:\n\nsh_css_pipe_load_binaries()\n  |-\u0026gt; load_video_binaries(mycs-\u0026gt;yuv_scaler_binary == NULL)\n  |\n  |-\u0026gt; sh_css_pipe_unload_binaries()\n        |-\u0026gt; unload_video_binaries()\n\nIn unload_video_binaries(), it calls to ia_css_binary_unload with argument\n\u0026amp;pipe-\u0026gt;pipe_settings.video.yuv_scaler_binary[i], which refers to the\nsame memory slot as mycs-\u0026gt;yuv_scaler_binary. Thus, a null-pointer\ndereference is triggered.(CVE-2024-38547)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: stk1160: fix bounds checking in stk1160_copy_video()\n\nThe subtract in this condition is reversed.  The -\u0026gt;length is the length\nof the buffer.  The -\u0026gt;bytesused is how many bytes we have copied thus\nfar.  When the condition is reversed that means the result of the\nsubtraction is always negative but since it\u0026apos;s unsigned then the result\nis a very high positive value.  That means the overflow check is never\ntrue.\n\nAdditionally, the -\u0026gt;bytesused doesn\u0026apos;t actually work for this purpose\nbecause we\u0026apos;re not writing to \u0026quot;buf-\u0026gt;mem + buf-\u0026gt;bytesused\u0026quot;.  Instead, the\nmath to calculate the destination where we are writing is a bit\ninvolved.  You calculate the number of full lines already written,\nmultiply by two, skip a line if necessary so that we start on an odd\nnumbered line, and add the offset into the line.\n\nTo fix this buffer overflow, just take the actual destination where we\nare writing, if the offset is already out of bounds print an error and\nreturn.  Otherwise, write up to buf-\u0026gt;length bytes.(CVE-2024-38621)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ns390/sclp: Prevent release of buffer in I/O\n\nWhen a task waiting for completion of a Store Data operation is\ninterrupted, an attempt is made to halt this operation. If this attempt\nfails due to a hardware or firmware problem, there is a chance that the\nSCLP facility might store data into buffers referenced by the original\noperation at a later time.\n\nHandle this situation by not releasing the referenced data buffers if\nthe halt attempt fails. For current use cases, this might result in a\nleak of few pages of memory in case of a rare hardware/firmware\nmalfunction.(CVE-2024-44969)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm cache: fix out-of-bounds access to the dirty bitset when resizing\n\ndm-cache checks the dirty bits of the cache blocks to be dropped when\nshrinking the fast device, but an index bug in bitset iteration causes\nout-of-bounds access.\n\nReproduce steps:\n\n1. create a cache device of 1024 cache blocks (128 bytes dirty bitset)\n\ndmsetup create cmeta --table \u0026quot;0 8192 linear /dev/sdc 0\u0026quot;\ndmsetup create cdata --table \u0026quot;0 131072 linear /dev/sdc 8192\u0026quot;\ndmsetup create corig --table \u0026quot;0 524288 linear /dev/sdc 262144\u0026quot;\ndd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct\ndmsetup create cache --table \u0026quot;0 524288 cache /dev/mapper/cmeta \\\n/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\u0026quot;\n\n2. shrink the fast device to 512 cache blocks, triggering out-of-bounds\n   access to the dirty bitset (offset 0x80)\n\ndmsetup suspend cache\ndmsetup reload cdata --table \u0026quot;0 65536 linear /dev/sdc 8192\u0026quot;\ndmsetup resume cdata\ndmsetup resume cache\n\nKASAN reports:\n\n  BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0\n  Read of size 8 at addr ffffc900000f3080 by task dmsetup/131\n\n  (...snip...)\n  The buggy address belongs to the virtual mapping at\n   [ffffc900000f3000, ffffc900000f5000) created by:\n   cache_ctr+0x176a/0x35f0\n\n  (...snip...)\n  Memory state around the buggy address:\n   ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n   ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n  \u0026gt;ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n                     ^\n   ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n   ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n\nFix by making the index post-incremented.(CVE-2024-50279)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915/hdcp: Add encoder check in hdcp2_get_capability\n\nAdd encoder check in intel_hdcp2_get_capability to avoid\nnull pointer error.(CVE-2024-53050)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/hns: Fix NULL pointer derefernce in hns_roce_map_mr_sg()\n\nib_map_mr_sg() allows ULPs to specify NULL as the sg_offset argument.\nThe driver needs to check whether it is a NULL pointer before\ndereferencing it.(CVE-2024-53226)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncachefiles: Fix NULL pointer dereference in object-\u0026gt;file\n\nAt present, the object-\u0026gt;file has the NULL pointer dereference problem in\nondemand-mode. The root cause is that the allocated fd and object-\u0026gt;file\nlifetime are inconsistent, and the user-space invocation to anon_fd uses\nobject-\u0026gt;file. Following is the process that triggers the issue:\n\n\t  [write fd]\t\t\t\t[umount]\ncachefiles_ondemand_fd_write_iter\n\t\t\t\t       fscache_cookie_state_machine\n\t\t\t\t\t cachefiles_withdraw_cookie\n  if (!file) return -ENOBUFS\n\t\t\t\t\t   cachefiles_clean_up_object\n\t\t\t\t\t     cachefiles_unmark_inode_in_use\n\t\t\t\t\t     fput(object-\u0026gt;file)\n\t\t\t\t\t     object-\u0026gt;file = NULL\n  // file NULL pointer dereference!\n  __cachefiles_write(..., file, ...)\n\nFix this issue by add an additional reference count to the object-\u0026gt;file\nbefore write/llseek, and decrement after it finished.(CVE-2024-56549)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix Out-of-Bounds Write in ksmbd_vfs_stream_write\n\nAn offset from client could be a negative value, It could allows\nto write data outside the bounds of the allocated buffer.\nNote that this issue is coming when setting\n\u0026apos;vfs objects = streams_xattr parameter\u0026apos; in ksmbd.conf..(CVE-2024-56626)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: hsr: avoid potential out-of-bound access in fill_frame_info()\n\nsyzbot is able to feed a packet with 14 bytes, pretending\nit is a vlan one.\n\nSince fill_frame_info() is relying on skb-\u0026gt;mac_len already,\nextend the check to cover this case.\n\nBUG: KMSAN: uninit-value in fill_frame_info net/hsr/hsr_forward.c:709 [inline]\n BUG: KMSAN: uninit-value in hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724\n  fill_frame_info net/hsr/hsr_forward.c:709 [inline]\n  hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724\n  hsr_dev_xmit+0x2f0/0x350 net/hsr/hsr_device.c:235\n  __netdev_start_xmit include/linux/netdevice.h:5002 [inline]\n  netdev_start_xmit include/linux/netdevice.h:5011 [inline]\n  xmit_one net/core/dev.c:3590 [inline]\n  dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3606\n  __dev_queue_xmit+0x366a/0x57d0 net/core/dev.c:4434\n  dev_queue_xmit include/linux/netdevice.h:3168 [inline]\n  packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276\n  packet_snd net/packet/af_packet.c:3146 [inline]\n  packet_sendmsg+0x91ae/0xa6f0 net/packet/af_packet.c:3178\n  sock_sendmsg_nosec net/socket.c:711 [inline]\n  __sock_sendmsg+0x30f/0x380 net/socket.c:726\n  __sys_sendto+0x594/0x750 net/socket.c:2197\n  __do_sys_sendto net/socket.c:2204 [inline]\n  __se_sys_sendto net/socket.c:2200 [inline]\n  __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200\n  x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nUninit was created at:\n  slab_post_alloc_hook mm/slub.c:4091 [inline]\n  slab_alloc_node mm/slub.c:4134 [inline]\n  kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186\n  kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587\n  __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678\n  alloc_skb include/linux/skbuff.h:1323 [inline]\n  alloc_skb_with_frags+0xc8/0xd00 net/core/skbuff.c:6612\n  sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2881\n  packet_alloc_skb net/packet/af_packet.c:2995 [inline]\n  packet_snd net/packet/af_packet.c:3089 [inline]\n  packet_sendmsg+0x74c6/0xa6f0 net/packet/af_packet.c:3178\n  sock_sendmsg_nosec net/socket.c:711 [inline]\n  __sock_sendmsg+0x30f/0x380 net/socket.c:726\n  __sys_sendto+0x594/0x750 net/socket.c:2197\n  __do_sys_sendto net/socket.c:2204 [inline]\n  __se_sys_sendto net/socket.c:2200 [inline]\n  __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200\n  x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-56648)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: pcrypt - Call crypto layer directly when padata_do_parallel() return -EBUSY\n\nSince commit 8f4f68e788c3 (\u0026quot;crypto: pcrypt - Fix hungtask for\nPADATA_RESET\u0026quot;), the pcrypt encryption and decryption operations return\n-EAGAIN when the CPU goes online or offline. In alg_test(), a WARN is\ngenerated when pcrypt_aead_decrypt() or pcrypt_aead_encrypt() returns\n-EAGAIN, the unnecessary panic will occur when panic_on_warn set 1.\nFix this issue by calling crypto layer directly without parallelization\nin that case.(CVE-2024-56690)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocteontx2-pf: handle otx2_mbox_get_rsp errors in otx2_ethtool.c\n\nAdd error pointer check after calling otx2_mbox_get_rsp().(CVE-2024-56728)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: check folio mapping after unlock in relocate_one_folio()\n\nWhen we call btrfs_read_folio() to bring a folio uptodate, we unlock the\nfolio. The result of that is that a different thread can modify the\nmapping (like remove it with invalidate) before we call folio_lock().\nThis results in an invalid page and we need to try again.\n\nIn particular, if we are relocating concurrently with aborting a\ntransaction, this can result in a crash like the following:\n\n  BUG: kernel NULL pointer dereference, address: 0000000000000000\n  PGD 0 P4D 0\n  Oops: 0000 [#1] SMP\n  CPU: 76 PID: 1411631 Comm: kworker/u322:5\n  Workqueue: events_unbound btrfs_reclaim_bgs_work\n  RIP: 0010:set_page_extent_mapped+0x20/0xb0\n  RSP: 0018:ffffc900516a7be8 EFLAGS: 00010246\n  RAX: ffffea009e851d08 RBX: ffffea009e0b1880 RCX: 0000000000000000\n  RDX: 0000000000000000 RSI: ffffc900516a7b90 RDI: ffffea009e0b1880\n  RBP: 0000000003573000 R08: 0000000000000001 R09: ffff88c07fd2f3f0\n  R10: 0000000000000000 R11: 0000194754b575be R12: 0000000003572000\n  R13: 0000000003572fff R14: 0000000000100cca R15: 0000000005582fff\n  FS:  0000000000000000(0000) GS:ffff88c07fd00000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 0000000000000000 CR3: 000000407d00f002 CR4: 00000000007706f0\n  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n  PKRU: 55555554\n  Call Trace:\n  \u0026lt;TASK\u0026gt;\n  ? __die+0x78/0xc0\n  ? page_fault_oops+0x2a8/0x3a0\n  ? __switch_to+0x133/0x530\n  ? wq_worker_running+0xa/0x40\n  ? exc_page_fault+0x63/0x130\n  ? asm_exc_page_fault+0x22/0x30\n  ? set_page_extent_mapped+0x20/0xb0\n  relocate_file_extent_cluster+0x1a7/0x940\n  relocate_data_extent+0xaf/0x120\n  relocate_block_group+0x20f/0x480\n  btrfs_relocate_block_group+0x152/0x320\n  btrfs_relocate_chunk+0x3d/0x120\n  btrfs_reclaim_bgs_work+0x2ae/0x4e0\n  process_scheduled_works+0x184/0x370\n  worker_thread+0xc6/0x3e0\n  ? blk_add_timer+0xb0/0xb0\n  kthread+0xae/0xe0\n  ? flush_tlb_kernel_range+0x90/0x90\n  ret_from_fork+0x2f/0x40\n  ? flush_tlb_kernel_range+0x90/0x90\n  ret_from_fork_asm+0x11/0x20\n  \u0026lt;/TASK\u0026gt;\n\nThis occurs because cleanup_one_transaction() calls\ndestroy_delalloc_inodes() which calls invalidate_inode_pages2() which\ntakes the folio_lock before setting mapping to NULL. We fail to check\nthis, and subsequently call set_extent_mapping(), which assumes that\nmapping != NULL (in fact it asserts that in debug mode)\n\nNote that the \u0026quot;fixes\u0026quot; patch here is not the one that introduced the\nrace (the very first iteration of this code from 2009) but a more recent\nchange that made this particular crash happen in practice.(CVE-2024-56758)","affected":[{"package":{"ecosystem":"openEuler:22.03-LTS-SP4","name":"kernel","purl":"pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-247.0.0.146.oe2203sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm","bpftool-debuginfo-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm","kernel-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm","kernel-debuginfo-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm","kernel-debugsource-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm","kernel-devel-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm","kernel-headers-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm","kernel-source-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm","kernel-tools-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm","kernel-tools-debuginfo-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm","kernel-tools-devel-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm","perf-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm","perf-debuginfo-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm","python3-perf-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm","python3-perf-debuginfo-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm"],"src":["kernel-5.10.0-247.0.0.146.oe2203sp4.src.rpm"],"x86_64":["bpftool-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm","bpftool-debuginfo-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm","kernel-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm","kernel-debuginfo-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm","kernel-debugsource-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm","kernel-devel-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm","kernel-headers-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm","kernel-source-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm","kernel-tools-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm","kernel-tools-debuginfo-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm","kernel-tools-devel-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm","perf-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm","perf-debuginfo-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm","python3-perf-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm","python3-perf-debuginfo-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1081"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-24858"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26602"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26820"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26857"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26956"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26966"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26969"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26974"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26981"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-27001"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38547"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38621"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-44969"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50279"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53050"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53226"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56549"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56626"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56648"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56690"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56728"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56758"}],"database_specific":{"severity":"High"}}