{"id":"OESA-2024-1497","summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvt: fix memory overlapping when deleting chars in the buffer\r\n\r\nA memory overlapping copy occurs when deleting a long line. This memory\noverlapping copy can cause data corruption when scr_memcpyw is optimized\nto memcpy because memcpy does not ensure its behavior if the destination\nbuffer overlaps with the source buffer. The line buffer is not always\nbroken, because the memcpy utilizes the hardware acceleration, whose\nresult is not deterministic.\r\n\r\nFix this problem by using replacing the scr_memcpyw with scr_memmovew.(CVE-2022-48627)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncrypto: qcom-rng - ensure buffer for generate is completely filled\r\n\r\nThe generate function in struct rng_alg expects that the destination\nbuffer is completely filled if the function returns 0. qcom_rng_read()\ncan run into a situation where the buffer is partially filled with\nrandomness and the remaining part of the buffer is zeroed since\nqcom_rng_generate() doesn't check the return value. This issue can\nbe reproduced by running the following from libkcapi:\r\n\r\n    kcapi-rng -b 9000000 > OUTFILE\r\n\r\nThe generated OUTFILE will have three huge sections that contain all\nzeros, and this is caused by the code where the test\n'val & PRNG_STATUS_DATA_AVAIL' fails.\r\n\r\nLet's fix this issue by ensuring that qcom_rng_read() always returns\nwith a full buffer if the function returns success. Let's also have\nqcom_rng_generate() return the correct value.\r\n\r\nHere's some statistics from the ent project\n(https://www.fourmilab.ch/random/) that shows information about the\nquality of the generated numbers:\r\n\r\n    $ ent -c qcom-random-before\n    Value Char Occurrences Fraction\n      0           606748   0.067416\n      1            33104   0.003678\n      2            33001   0.003667\n    ...\n    253   �        32883   0.003654\n    254   �        33035   0.003671\n    255   �        33239   0.003693\r\n\r\n    Total:       9000000   1.000000\r\n\r\n    Entropy = 7.811590 bits per byte.\r\n\r\n    Optimum compression would reduce the size\n    of this 9000000 byte file by 2 percent.\r\n\r\n    Chi square distribution for 9000000 samples is 9329962.81, and\n    randomly would exceed this value less than 0.01 percent of the\n    times.\r\n\r\n    Arithmetic mean value of data bytes is 119.3731 (127.5 = random).\n    Monte Carlo value for Pi is 3.197293333 (error 1.77 percent).\n    Serial correlation coefficient is 0.159130 (totally uncorrelated =\n    0.0).\r\n\r\nWithout this patch, the results of the chi-square test is 0.01%, and\nthe numbers are certainly not random according to ent's project page.\nThe results improve with this patch:\r\n\r\n    $ ent -c qcom-random-after\n    Value Char Occurrences Fraction\n      0            35432   0.003937\n      1            35127   0.003903\n      2            35424   0.003936\n    ...\n    253   �        35201   0.003911\n    254   �        34835   0.003871\n    255   �        35368   0.003930\r\n\r\n    Total:       9000000   1.000000\r\n\r\n    Entropy = 7.999979 bits per byte.\r\n\r\n    Optimum compression would reduce the size\n    of this 9000000 byte file by 0 percent.\r\n\r\n    Chi square distribution for 9000000 samples is 258.77, and randomly\n    would exceed this value 42.24 percent of the times.\r\n\r\n    Arithmetic mean value of data bytes is 127.5006 (127.5 = random).\n    Monte Carlo value for Pi is 3.141277333 (error 0.01 percent).\n    Serial correlation coefficient is 0.000468 (totally uncorrelated =\n    0.0).\r\n\r\nThis change was tested on a Nexus 5 phone (msm8974 SoC).(CVE-2022-48629)\r\n\r\nThe brcm80211 component in the Linux kernel through 6.5.10 has a brcmf_cfg80211_detach use-after-free in the device unplugging (disconnect the USB by hotplug) code. For physically proximate attackers with local access, this "could be exploited in a real world scenario." This is related to brcmf_cfg80211_escan_timeout_worker in drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c.(CVE-2023-47233)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm: Don't unref the same fb many times by mistake due to deadlock handling\r\n\r\nIf we get a deadlock after the fb lookup in drm_mode_page_flip_ioctl()\nwe proceed to unref the fb and then retry the whole thing from the top.\nBut we forget to reset the fb pointer back to NULL, and so if we then\nget another error during the retry, before the fb lookup, we proceed\nthe unref the same fb again without having gotten another reference.\nThe end result is that the fb will (eventually) end up being freed\nwhile it's still in use.\r\n\r\nReset fb to NULL once we've unreffed it to avoid doing it again\nuntil we've done another fb lookup.\r\n\r\nThis turned out to be pretty easy to hit on a DG2 when doing async\nflips (and CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y). The first symptom I\nsaw that drm_closefb() simply got stuck in a busy loop while walking\nthe framebuffer list. Fortunately I was able to convince it to oops\ninstead, and from there it was easier to track down the culprit.(CVE-2023-52486)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nx86/alternatives: Disable KASAN in apply_alternatives()\r\n\r\nFei has reported that KASAN triggers during apply_alternatives() on\na 5-level paging machine:\r\n\r\n\tBUG: KASAN: out-of-bounds in rcu_is_watching()\n\tRead of size 4 at addr ff110003ee6419a0 by task swapper/0/0\n\t...\n\t__asan_load4()\n\trcu_is_watching()\n\ttrace_hardirqs_on()\n\ttext_poke_early()\n\tapply_alternatives()\n\t...\r\n\r\nOn machines with 5-level paging, cpu_feature_enabled(X86_FEATURE_LA57)\ngets patched. It includes KASAN code, where KASAN_SHADOW_START depends on\n__VIRTUAL_MASK_SHIFT, which is defined with cpu_feature_enabled().\r\n\r\nKASAN gets confused when apply_alternatives() patches the\nKASAN_SHADOW_START users. A test patch that makes KASAN_SHADOW_START\nstatic, by replacing __VIRTUAL_MASK_SHIFT with 56, works around the issue.\r\n\r\nFix it for real by disabling KASAN while the kernel is patching alternatives.\r\n\r\n[ mingo: updated the changelog ](CVE-2023-52504)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: nfc: llcp: Add lock when modifying device list\r\n\r\nThe device list needs its associated lock held when modifying it, or the\nlist could become corrupted, as syzbot discovered.(CVE-2023-52524)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npowerpc/mm: Fix null-pointer dereference in pgtable_cache_add\r\n\r\nkasprintf() returns a pointer to dynamically allocated memory\nwhich can be NULL upon failure. Ensure the allocation was successful\nby checking the pointer validity.(CVE-2023-52607)\r\n\r\nA null pointer dereference vulnerability was found in ath10k_wmi_tlv_op_pull_mgmt_tx_compl_ev() in drivers/net/wireless/ath/ath10k/wmi-tlv.c in the Linux kernel. This issue could be exploited to trigger a denial of service.(CVE-2023-7042)\r\n\r\nA race condition was found in the Linux kernel's media/xc4000 device driver in xc4000 xc4000_get_frequency() function. This can result in return value overflow issue, possibly leading to malfunction or denial of service issue.\r\n\r\n\r\n\r\n\n(CVE-2024-24861)\r\n\r\ncreate_empty_lvol in drivers/mtd/ubi/vtbl.c in the Linux kernel through 6.7.4 can attempt to allocate zero bytes, and crash, because of a missing check for ubi->leb_size.(CVE-2024-25739)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/smc: fix illegal rmb_desc access in SMC-D connection dump\r\n\r\nA crash was found when dumping SMC-D connections. It can be reproduced\nby following steps:\r\n\r\n- run nginx/wrk test:\n  smc_run nginx\n  smc_run wrk -t 16 -c 1000 -d <duration> -H 'Connection: Close' <URL>\r\n\r\n- continuously dump SMC-D connections in parallel:\n  watch -n 1 'smcss -D'\r\n\r\n BUG: kernel NULL pointer dereference, address: 0000000000000030\n CPU: 2 PID: 7204 Comm: smcss Kdump: loaded Tainted: G\tE      6.7.0+ #55\n RIP: 0010:__smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag]\n Call Trace:\n  <TASK>\n  ? __die+0x24/0x70\n  ? page_fault_oops+0x66/0x150\n  ? exc_page_fault+0x69/0x140\n  ? asm_exc_page_fault+0x26/0x30\n  ? __smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag]\n  ? __kmalloc_node_track_caller+0x35d/0x430\n  ? __alloc_skb+0x77/0x170\n  smc_diag_dump_proto+0xd0/0xf0 [smc_diag]\n  smc_diag_dump+0x26/0x60 [smc_diag]\n  netlink_dump+0x19f/0x320\n  __netlink_dump_start+0x1dc/0x300\n  smc_diag_handler_dump+0x6a/0x80 [smc_diag]\n  ? __pfx_smc_diag_dump+0x10/0x10 [smc_diag]\n  sock_diag_rcv_msg+0x121/0x140\n  ? __pfx_sock_diag_rcv_msg+0x10/0x10\n  netlink_rcv_skb+0x5a/0x110\n  sock_diag_rcv+0x28/0x40\n  netlink_unicast+0x22a/0x330\n  netlink_sendmsg+0x1f8/0x420\n  __sock_sendmsg+0xb0/0xc0\n  ____sys_sendmsg+0x24e/0x300\n  ? copy_msghdr_from_user+0x62/0x80\n  ___sys_sendmsg+0x7c/0xd0\n  ? __do_fault+0x34/0x160\n  ? do_read_fault+0x5f/0x100\n  ? do_fault+0xb0/0x110\n  ? __handle_mm_fault+0x2b0/0x6c0\n  __sys_sendmsg+0x4d/0x80\n  do_syscall_64+0x69/0x180\n  entry_SYSCALL_64_after_hwframe+0x6e/0x76\r\n\r\nIt is possible that the connection is in process of being established\nwhen we dump it. Assumed that the connection has been registered in a\nlink group by smc_conn_create() but the rmb_desc has not yet been\ninitialized by smc_buf_create(), thus causing the illegal access to\nconn->rmb_desc. So fix it by checking before dump.(CVE-2024-26615)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: sh: aica: reorder cleanup operations to avoid UAF bugs\r\n\r\nThe dreamcastcard->timer could schedule the spu_dma_work and the\nspu_dma_work could also arm the dreamcastcard->timer.\r\n\r\nWhen the snd_pcm_substream is closing, the aica_channel will be\ndeallocated. But it could still be dereferenced in the worker\nthread. The reason is that del_timer() will return directly\nregardless of whether the timer handler is running or not and\nthe worker could be rescheduled in the timer handler. As a result,\nthe UAF bug will happen. The racy situation is shown below:\r\n\r\n      (Thread 1)                 |      (Thread 2)\nsnd_aicapcm_pcm_close()          |\n ...                             |  run_spu_dma() //worker\n                                 |    mod_timer()\n  flush_work()                   |\n  del_timer()                    |  aica_period_elapsed() //timer\n  kfree(dreamcastcard->channel)  |    schedule_work()\n                                 |  run_spu_dma() //worker\n  ...                            |    dreamcastcard->channel-> //USE\r\n\r\nIn order to mitigate this bug and other possible corner cases,\ncall mod_timer() conditionally in run_spu_dma(), then implement\nPCM sync_stop op to cancel both the timer and worker. The sync_stop\nop will be called from PCM core appropriately when needed.(CVE-2024-26654)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntipc: Check the bearer type before calling tipc_udp_nl_bearer_add()\r\n\r\nsyzbot reported the following general protection fault [1]:\r\n\r\ngeneral protection fault, probably for non-canonical address 0xdffffc0000000010: 0000 [#1] PREEMPT SMP KASAN\nKASAN: null-ptr-deref in range [0x0000000000000080-0x0000000000000087]\n...\nRIP: 0010:tipc_udp_is_known_peer+0x9c/0x250 net/tipc/udp_media.c:291\n...\nCall Trace:\n <TASK>\n tipc_udp_nl_bearer_add+0x212/0x2f0 net/tipc/udp_media.c:646\n tipc_nl_bearer_add+0x21e/0x360 net/tipc/bearer.c:1089\n genl_family_rcv_msg_doit+0x1fc/0x2e0 net/netlink/genetlink.c:972\n genl_family_rcv_msg net/netlink/genetlink.c:1052 [inline]\n genl_rcv_msg+0x561/0x800 net/netlink/genetlink.c:1067\n netlink_rcv_skb+0x16b/0x440 net/netlink/af_netlink.c:2544\n genl_rcv+0x28/0x40 net/netlink/genetlink.c:1076\n netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]\n netlink_unicast+0x53b/0x810 net/netlink/af_netlink.c:1367\n netlink_sendmsg+0x8b7/0xd70 net/netlink/af_netlink.c:1909\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0xd5/0x180 net/socket.c:745\n ____sys_sendmsg+0x6ac/0x940 net/socket.c:2584\n ___sys_sendmsg+0x135/0x1d0 net/socket.c:2638\n __sys_sendmsg+0x117/0x1e0 net/socket.c:2667\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nThe cause of this issue is that when tipc_nl_bearer_add() is called with\nthe TIPC_NLA_BEARER_UDP_OPTS attribute, tipc_udp_nl_bearer_add() is called\neven if the bearer is not UDP.\r\n\r\ntipc_udp_is_known_peer() called by tipc_udp_nl_bearer_add() assumes that\nthe media_ptr field of the tipc_bearer has an udp_bearer type object, so\nthe function goes crazy for non-UDP bearers.\r\n\r\nThis patch fixes the issue by checking the bearer type before calling\ntipc_udp_nl_bearer_add() in tipc_nl_bearer_add().(CVE-2024-26663)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix hang in nilfs_lookup_dirty_data_buffers()\r\n\r\nSyzbot reported a hang issue in migrate_pages_batch() called by mbind()\nand nilfs_lookup_dirty_data_buffers() called in the log writer of nilfs2.\r\n\r\nWhile migrate_pages_batch() locks a folio and waits for the writeback to\ncomplete, the log writer thread that should bring the writeback to\ncompletion picks up the folio being written back in\nnilfs_lookup_dirty_data_buffers() that it calls for subsequent log\ncreation and was trying to lock the folio.  Thus causing a deadlock.\r\n\r\nIn the first place, it is unexpected that folios/pages in the middle of\nwriteback will be updated and become dirty.  Nilfs2 adds a checksum to\nverify the validity of the log being written and uses it for recovery at\nmount, so data changes during writeback are suppressed.  Since this is\nbroken, an unclean shutdown could potentially cause recovery to fail.\r\n\r\nInvestigation revealed that the root cause is that the wait for writeback\ncompletion in nilfs_page_mkwrite() is conditional, and if the backing\ndevice does not require stable writes, data may be modified without\nwaiting.\r\n\r\nFix these issues by making nilfs_page_mkwrite() wait for writeback to\nfinish regardless of the stable write requirement of the backing device.(CVE-2024-26696)","modified":"2026-03-11T06:44:23.005636Z","published":"2024-04-26T11:07:49Z","upstream":["CVE-2022-48627","CVE-2022-48629","CVE-2023-47233","CVE-2023-52486","CVE-2023-52504","CVE-2023-52524","CVE-2023-52607","CVE-2023-7042","CVE-2024-24861","CVE-2024-25739","CVE-2024-26615","CVE-2024-26654","CVE-2024-26663","CVE-2024-26696"],"database_specific":{"severity":"Medium"},"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1497"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48627"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48629"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-47233"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52486"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52504"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52524"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52607"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-7042"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-24861"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-25739"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26615"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26654"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26663"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26696"}],"affected":[{"package":{"name":"kernel","ecosystem":"openEuler:20.03-LTS-SP4","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-20.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.19.90-2404.3.0.0274.oe2003sp4"}]}],"ecosystem_specific":{"x86_64":["kernel-4.19.90-2404.3.0.0274.oe2003sp4.x86_64.rpm","kernel-source-4.19.90-2404.3.0.0274.oe2003sp4.x86_64.rpm","perf-4.19.90-2404.3.0.0274.oe2003sp4.x86_64.rpm","kernel-tools-devel-4.19.90-2404.3.0.0274.oe2003sp4.x86_64.rpm","kernel-debuginfo-4.19.90-2404.3.0.0274.oe2003sp4.x86_64.rpm","bpftool-4.19.90-2404.3.0.0274.oe2003sp4.x86_64.rpm","python3-perf-debuginfo-4.19.90-2404.3.0.0274.oe2003sp4.x86_64.rpm","kernel-debugsource-4.19.90-2404.3.0.0274.oe2003sp4.x86_64.rpm","bpftool-debuginfo-4.19.90-2404.3.0.0274.oe2003sp4.x86_64.rpm","perf-debuginfo-4.19.90-2404.3.0.0274.oe2003sp4.x86_64.rpm","kernel-tools-4.19.90-2404.3.0.0274.oe2003sp4.x86_64.rpm","python3-perf-4.19.90-2404.3.0.0274.oe2003sp4.x86_64.rpm","python2-perf-debuginfo-4.19.90-2404.3.0.0274.oe2003sp4.x86_64.rpm","python2-perf-4.19.90-2404.3.0.0274.oe2003sp4.x86_64.rpm","kernel-tools-debuginfo-4.19.90-2404.3.0.0274.oe2003sp4.x86_64.rpm","kernel-devel-4.19.90-2404.3.0.0274.oe2003sp4.x86_64.rpm"],"aarch64":["kernel-4.19.90-2404.3.0.0274.oe2003sp4.aarch64.rpm","kernel-source-4.19.90-2404.3.0.0274.oe2003sp4.aarch64.rpm","kernel-devel-4.19.90-2404.3.0.0274.oe2003sp4.aarch64.rpm","kernel-debugsource-4.19.90-2404.3.0.0274.oe2003sp4.aarch64.rpm","kernel-tools-devel-4.19.90-2404.3.0.0274.oe2003sp4.aarch64.rpm","perf-4.19.90-2404.3.0.0274.oe2003sp4.aarch64.rpm","bpftool-debuginfo-4.19.90-2404.3.0.0274.oe2003sp4.aarch64.rpm","kernel-debuginfo-4.19.90-2404.3.0.0274.oe2003sp4.aarch64.rpm","kernel-tools-debuginfo-4.19.90-2404.3.0.0274.oe2003sp4.aarch64.rpm","python3-perf-4.19.90-2404.3.0.0274.oe2003sp4.aarch64.rpm","bpftool-4.19.90-2404.3.0.0274.oe2003sp4.aarch64.rpm","kernel-tools-4.19.90-2404.3.0.0274.oe2003sp4.aarch64.rpm","perf-debuginfo-4.19.90-2404.3.0.0274.oe2003sp4.aarch64.rpm","python3-perf-debuginfo-4.19.90-2404.3.0.0274.oe2003sp4.aarch64.rpm","python2-perf-debuginfo-4.19.90-2404.3.0.0274.oe2003sp4.aarch64.rpm","python2-perf-4.19.90-2404.3.0.0274.oe2003sp4.aarch64.rpm"],"src":["kernel-4.19.90-2404.3.0.0274.oe2003sp4.src.rpm"]},"database_specific":{"source":"https://repo.openeuler.org/security/data/osv/OESA-2024-1497.json"}}],"schema_version":"1.7.5"}