GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

OESA-2024-1496 (CVE-2022-48627)

Vulnerability from osv_openeuler – Published: 2024-04-26 11:06 – Updated: 2026-08-06 11:06 – Source website
VLAI
Summary
kernel security update
Details

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

vt: fix memory overlapping when deleting chars in the buffer

A memory overlapping copy occurs when deleting a long line. This memory overlapping copy can cause data corruption when scr_memcpyw is optimized to memcpy because memcpy does not ensure its behavior if the destination buffer overlaps with the source buffer. The line buffer is not always broken, because the memcpy utilizes the hardware acceleration, whose result is not deterministic.

Fix this problem by using replacing the scr_memcpyw with scr_memmovew.(CVE-2022-48627)

In the Linux kernel, the following vulnerability has been resolved:

crypto: qcom-rng - ensure buffer for generate is completely filled

The generate function in struct rng_alg expects that the destination buffer is completely filled if the function returns 0. qcom_rng_read() can run into a situation where the buffer is partially filled with randomness and the remaining part of the buffer is zeroed since qcom_rng_generate() doesn't check the return value. This issue can be reproduced by running the following from libkcapi:

kcapi-rng -b 9000000 > OUTFILE

The generated OUTFILE will have three huge sections that contain all zeros, and this is caused by the code where the test 'val & PRNG_STATUS_DATA_AVAIL' fails.

Let's fix this issue by ensuring that qcom_rng_read() always returns with a full buffer if the function returns success. Let's also have qcom_rng_generate() return the correct value.

Here's some statistics from the ent project (https://www.fourmilab.ch/random/) that shows information about the quality of the generated numbers:

$ ent -c qcom-random-before
Value Char Occurrences Fraction
  0           606748   0.067416
  1            33104   0.003678
  2            33001   0.003667
...
253   �        32883   0.003654
254   �        33035   0.003671
255   �        33239   0.003693

Total:       9000000   1.000000

Entropy = 7.811590 bits per byte.

Optimum compression would reduce the size
of this 9000000 byte file by 2 percent.

Chi square distribution for 9000000 samples is 9329962.81, and
randomly would exceed this value less than 0.01 percent of the
times.

Arithmetic mean value of data bytes is 119.3731 (127.5 = random).
Monte Carlo value for Pi is 3.197293333 (error 1.77 percent).
Serial correlation coefficient is 0.159130 (totally uncorrelated =
0.0).

Without this patch, the results of the chi-square test is 0.01%, and the numbers are certainly not random according to ent's project page. The results improve with this patch:

$ ent -c qcom-random-after
Value Char Occurrences Fraction
  0            35432   0.003937
  1            35127   0.003903
  2            35424   0.003936
...
253   �        35201   0.003911
254   �        34835   0.003871
255   �        35368   0.003930

Total:       9000000   1.000000

Entropy = 7.999979 bits per byte.

Optimum compression would reduce the size
of this 9000000 byte file by 0 percent.

Chi square distribution for 9000000 samples is 258.77, and randomly
would exceed this value 42.24 percent of the times.

Arithmetic mean value of data bytes is 127.5006 (127.5 = random).
Monte Carlo value for Pi is 3.141277333 (error 0.01 percent).
Serial correlation coefficient is 0.000468 (totally uncorrelated =
0.0).

This change was tested on a Nexus 5 phone (msm8974 SoC).(CVE-2022-48629)

The 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)

In the Linux kernel, the following vulnerability has been resolved:

drm: Don't unref the same fb many times by mistake due to deadlock handling

If we get a deadlock after the fb lookup in drm_mode_page_flip_ioctl() we proceed to unref the fb and then retry the whole thing from the top. But we forget to reset the fb pointer back to NULL, and so if we then get another error during the retry, before the fb lookup, we proceed the unref the same fb again without having gotten another reference. The end result is that the fb will (eventually) end up being freed while it's still in use.

Reset fb to NULL once we've unreffed it to avoid doing it again until we've done another fb lookup.

This turned out to be pretty easy to hit on a DG2 when doing async flips (and CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y). The first symptom I saw that drm_closefb() simply got stuck in a busy loop while walking the framebuffer list. Fortunately I was able to convince it to oops instead, and from there it was easier to track down the culprit.(CVE-2023-52486)

In the Linux kernel, the following vulnerability has been resolved:

x86/alternatives: Disable KASAN in apply_alternatives()

Fei has reported that KASAN triggers during apply_alternatives() on a 5-level paging machine:

BUG: KASAN: out-of-bounds in rcu_is_watching()
Read of size 4 at addr ff110003ee6419a0 by task swapper/0/0
...
__asan_load4()
rcu_is_watching()
trace_hardirqs_on()
text_poke_early()
apply_alternatives()
...

On machines with 5-level paging, cpu_feature_enabled(X86_FEATURE_LA57) gets patched. It includes KASAN code, where KASAN_SHADOW_START depends on __VIRTUAL_MASK_SHIFT, which is defined with cpu_feature_enabled().

KASAN gets confused when apply_alternatives() patches the KASAN_SHADOW_START users. A test patch that makes KASAN_SHADOW_START static, by replacing __VIRTUAL_MASK_SHIFT with 56, works around the issue.

Fix it for real by disabling KASAN while the kernel is patching alternatives.

mingo: updated the changelog

In the Linux kernel, the following vulnerability has been resolved:

net: nfc: llcp: Add lock when modifying device list

The device list needs its associated lock held when modifying it, or the list could become corrupted, as syzbot discovered.(CVE-2023-52524)

In the Linux kernel, the following vulnerability has been resolved:

team: fix null-ptr-deref when team device type is changed

Get a null-ptr-deref bug as follows with reproducer [1].

BUG: kernel NULL pointer dereference, address: 0000000000000228 ... RIP: 0010:vlan_dev_hard_header+0x35/0x140 [8021q] ... Call Trace: <TASK> ? __die+0x24/0x70 ? page_fault_oops+0x82/0x150 ? exc_page_fault+0x69/0x150 ? asm_exc_page_fault+0x26/0x30 ? vlan_dev_hard_header+0x35/0x140 [8021q] ? vlan_dev_hard_header+0x8e/0x140 [8021q] neigh_connected_output+0xb2/0x100 ip6_finish_output2+0x1cb/0x520 ? nf_hook_slow+0x43/0xc0 ? ip6_mtu+0x46/0x80 ip6_finish_output+0x2a/0xb0 mld_sendpack+0x18f/0x250 mld_ifc_work+0x39/0x160 process_one_work+0x1e6/0x3f0 worker_thread+0x4d/0x2f0 ? __pfx_worker_thread+0x10/0x10 kthread+0xe5/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30

[1] $ teamd -t team0 -d -c '{"runner": {"name": "loadbalance"}}' $ ip link add name t-dummy type dummy $ ip link add link t-dummy name t-dummy.100 type vlan id 100 $ ip link add name t-nlmon type nlmon $ ip link set t-nlmon master team0 $ ip link set t-nlmon nomaster $ ip link set t-dummy up $ ip link set team0 up $ ip link set t-dummy.100 down $ ip link set t-dummy.100 master team0

When enslave a vlan device to team device and team device type is changed from non-ether to ether, header_ops of team device is changed to vlan_header_ops. That is incorrect and will trigger null-ptr-deref for vlan->real_dev in vlan_dev_hard_header() because team device is not a vlan device.

Cache eth_header_ops in team_setup(), then assign cached header_ops to header_ops of team net device when its type is changed from non-ether to ether to fix the bug.(CVE-2023-52574)

In the Linux kernel, the following vulnerability has been resolved:

powerpc/mm: Fix null-pointer dereference in pgtable_cache_add

kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Ensure the allocation was successful by checking the pointer validity.(CVE-2023-52607)

A 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)

A 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.

(CVE-2024-24861)

create_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)

In the Linux kernel, the following vulnerability has been resolved:

net/smc: fix illegal rmb_desc access in SMC-D connection dump

A crash was found when dumping SMC-D connections. It can be reproduced by following steps:

  • run nginx/wrk test: smc_run nginx smc_run wrk -t 16 -c 1000 -d <duration> -H 'Connection: Close' <URL>

  • continuously dump SMC-D connections in parallel: watch -n 1 'smcss -D'

BUG: kernel NULL pointer dereference, address: 0000000000000030 CPU: 2 PID: 7204 Comm: smcss Kdump: loaded Tainted: G E 6.7.0+ #55 RIP: 0010:__smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag] Call Trace: <TASK> ? __die+0x24/0x70 ? page_fault_oops+0x66/0x150 ? exc_page_fault+0x69/0x140 ? asm_exc_page_fault+0x26/0x30 ? __smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag] ? __kmalloc_node_track_caller+0x35d/0x430 ? __alloc_skb+0x77/0x170 smc_diag_dump_proto+0xd0/0xf0 [smc_diag] smc_diag_dump+0x26/0x60 [smc_diag] netlink_dump+0x19f/0x320 __netlink_dump_start+0x1dc/0x300 smc_diag_handler_dump+0x6a/0x80 [smc_diag] ? __pfx_smc_diag_dump+0x10/0x10 [smc_diag] sock_diag_rcv_msg+0x121/0x140 ? __pfx_sock_diag_rcv_msg+0x10/0x10 netlink_rcv_skb+0x5a/0x110 sock_diag_rcv+0x28/0x40 netlink_unicast+0x22a/0x330 netlink_sendmsg+0x1f8/0x420 __sock_sendmsg+0xb0/0xc0 _syssendmsg+0x24e/0x300 ? copy_msghdr_from_user+0x62/0x80 _sys_sendmsg+0x7c/0xd0 ? __do_fault+0x34/0x160 ? do_read_fault+0x5f/0x100 ? do_fault+0xb0/0x110 ? __handle_mm_fault+0x2b0/0x6c0 __sys_sendmsg+0x4d/0x80 do_syscall_64+0x69/0x180 entry_SYSCALL_64_after_hwframe+0x6e/0x76

It is possible that the connection is in process of being established when we dump it. Assumed that the connection has been registered in a link group by smc_conn_create() but the rmb_desc has not yet been initialized by smc_buf_create(), thus causing the illegal access to conn->rmb_desc. So fix it by checking before dump.(CVE-2024-26615)

In the Linux kernel, the following vulnerability has been resolved:

ALSA: sh: aica: reorder cleanup operations to avoid UAF bugs

The dreamcastcard->timer could schedule the spu_dma_work and the spu_dma_work could also arm the dreamcastcard->timer.

When the snd_pcm_substream is closing, the aica_channel will be deallocated. But it could still be dereferenced in the worker thread. The reason is that del_timer() will return directly regardless of whether the timer handler is running or not and the worker could be rescheduled in the timer handler. As a result, the UAF bug will happen. The racy situation is shown below:

  (Thread 1)                 |      (Thread 2)

snd_aicapcm_pcm_close() | ... | run_spu_dma() //worker | mod_timer() flush_work() | del_timer() | aica_period_elapsed() //timer kfree(dreamcastcard->channel) | schedule_work() | run_spu_dma() //worker ... | dreamcastcard->channel-> //USE

In order to mitigate this bug and other possible corner cases, call mod_timer() conditionally in run_spu_dma(), then implement PCM sync_stop op to cancel both the timer and worker. The sync_stop op will be called from PCM core appropriately when needed.(CVE-2024-26654)

In the Linux kernel, the following vulnerability has been resolved:

tipc: Check the bearer type before calling tipc_udp_nl_bearer_add()

syzbot reported the following general protection fault [1]:

general protection fault, probably for non-canonical address 0xdffffc0000000010: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000080-0x0000000000000087] ... RIP: 0010:tipc_udp_is_known_peer+0x9c/0x250 net/tipc/udp_media.c:291 ... Call Trace: <TASK> tipc_udp_nl_bearer_add+0x212/0x2f0 net/tipc/udp_media.c:646 tipc_nl_bearer_add+0x21e/0x360 net/tipc/bearer.c:1089 genl_family_rcv_msg_doit+0x1fc/0x2e0 net/netlink/genetlink.c:972 genl_family_rcv_msg net/netlink/genetlink.c:1052 [inline] genl_rcv_msg+0x561/0x800 net/netlink/genetlink.c:1067 netlink_rcv_skb+0x16b/0x440 net/netlink/af_netlink.c:2544 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1076 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x53b/0x810 net/netlink/af_netlink.c:1367 netlink_sendmsg+0x8b7/0xd70 net/netlink/af_netlink.c:1909 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0xd5/0x180 net/socket.c:745 _syssendmsg+0x6ac/0x940 net/socket.c:2584 _sys_sendmsg+0x135/0x1d0 net/socket.c:2638 __sys_sendmsg+0x117/0x1e0 net/socket.c:2667 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b

The cause of this issue is that when tipc_nl_bearer_add() is called with the TIPC_NLA_BEARER_UDP_OPTS attribute, tipc_udp_nl_bearer_add() is called even if the bearer is not UDP.

tipc_udp_is_known_peer() called by tipc_udp_nl_bearer_add() assumes that the media_ptr field of the tipc_bearer has an udp_bearer type object, so the function goes crazy for non-UDP bearers.

This patch fixes the issue by checking the bearer type before calling tipc_udp_nl_bearer_add() in tipc_nl_bearer_add().(CVE-2024-26663)

In the Linux kernel, the following vulnerability has been resolved:

nilfs2: fix hang in nilfs_lookup_dirty_data_buffers()

Syzbot reported a hang issue in migrate_pages_batch() called by mbind() and nilfs_lookup_dirty_data_buffers() called in the log writer of nilfs2.

While migrate_pages_batch() locks a folio and waits for the writeback to complete, the log writer thread that should bring the writeback to completion picks up the folio being written back in nilfs_lookup_dirty_data_buffers() that it calls for subsequent log creation and was trying to lock the folio. Thus causing a deadlock.

In the first place, it is unexpected that folios/pages in the middle of writeback will be updated and become dirty. Nilfs2 adds a checksum to verify the validity of the log being written and uses it for recovery at mount, so data changes during writeback are suppressed. Since this is broken, an unclean shutdown could potentially cause recovery to fail.

Investigation revealed that the root cause is that the wait for writeback completion in nilfs_page_mkwrite() is conditional, and if the backing device does not require stable writes, data may be modified without waiting.

Fix these issues by making nilfs_page_mkwrite() wait for writeback to finish regardless of the stable write requirement of the backing device.(CVE-2024-26696)

Severity
6.3 (Medium)
CVSS:3.1/AV:P/AC:L/PR:H/UI:N/S:C/C:L/I:L/A:H
References
To clipboard 

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "kernel-debugsource-4.19.90-2404.3.0.0247.oe1.aarch64.rpm",
          "kernel-tools-4.19.90-2404.3.0.0247.oe1.aarch64.rpm",
          "python2-perf-4.19.90-2404.3.0.0247.oe1.aarch64.rpm",
          "bpftool-4.19.90-2404.3.0.0247.oe1.aarch64.rpm",
          "kernel-tools-devel-4.19.90-2404.3.0.0247.oe1.aarch64.rpm",
          "kernel-debuginfo-4.19.90-2404.3.0.0247.oe1.aarch64.rpm",
          "kernel-source-4.19.90-2404.3.0.0247.oe1.aarch64.rpm",
          "kernel-tools-debuginfo-4.19.90-2404.3.0.0247.oe1.aarch64.rpm",
          "python3-perf-debuginfo-4.19.90-2404.3.0.0247.oe1.aarch64.rpm",
          "python3-perf-4.19.90-2404.3.0.0247.oe1.aarch64.rpm",
          "kernel-devel-4.19.90-2404.3.0.0247.oe1.aarch64.rpm",
          "perf-debuginfo-4.19.90-2404.3.0.0247.oe1.aarch64.rpm",
          "bpftool-debuginfo-4.19.90-2404.3.0.0247.oe1.aarch64.rpm",
          "python2-perf-debuginfo-4.19.90-2404.3.0.0247.oe1.aarch64.rpm",
          "perf-4.19.90-2404.3.0.0247.oe1.aarch64.rpm",
          "kernel-4.19.90-2404.3.0.0247.oe1.aarch64.rpm"
        ],
        "src": [
          "kernel-4.19.90-2404.3.0.0247.oe1.src.rpm"
        ],
        "x86_64": [
          "python3-perf-debuginfo-4.19.90-2404.3.0.0247.oe1.x86_64.rpm",
          "kernel-devel-4.19.90-2404.3.0.0247.oe1.x86_64.rpm",
          "kernel-debuginfo-4.19.90-2404.3.0.0247.oe1.x86_64.rpm",
          "perf-debuginfo-4.19.90-2404.3.0.0247.oe1.x86_64.rpm",
          "bpftool-debuginfo-4.19.90-2404.3.0.0247.oe1.x86_64.rpm",
          "python2-perf-4.19.90-2404.3.0.0247.oe1.x86_64.rpm",
          "kernel-tools-4.19.90-2404.3.0.0247.oe1.x86_64.rpm",
          "kernel-source-4.19.90-2404.3.0.0247.oe1.x86_64.rpm",
          "kernel-4.19.90-2404.3.0.0247.oe1.x86_64.rpm",
          "perf-4.19.90-2404.3.0.0247.oe1.x86_64.rpm",
          "bpftool-4.19.90-2404.3.0.0247.oe1.x86_64.rpm",
          "kernel-tools-devel-4.19.90-2404.3.0.0247.oe1.x86_64.rpm",
          "python2-perf-debuginfo-4.19.90-2404.3.0.0247.oe1.x86_64.rpm",
          "kernel-tools-debuginfo-4.19.90-2404.3.0.0247.oe1.x86_64.rpm",
          "kernel-debugsource-4.19.90-2404.3.0.0247.oe1.x86_64.rpm",
          "python3-perf-4.19.90-2404.3.0.0247.oe1.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:20.03-LTS-SP1",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP1"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.19.90-2404.3.0.0247.oe1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "Medium"
  },
  "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\u0026apos;t check the return value. This issue can\nbe reproduced by running the following from libkcapi:\r\n\r\n    kcapi-rng -b 9000000 \u0026gt; 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\u0026apos;val \u0026amp; PRNG_STATUS_DATA_AVAIL\u0026apos; fails.\r\n\r\nLet\u0026apos;s fix this issue by ensuring that qcom_rng_read() always returns\nwith a full buffer if the function returns success. Let\u0026apos;s also have\nqcom_rng_generate() return the correct value.\r\n\r\nHere\u0026apos;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   \ufffd        32883   0.003654\n    254   \ufffd        33035   0.003671\n    255   \ufffd        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\u0026apos;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   \ufffd        35201   0.003911\n    254   \ufffd        34835   0.003871\n    255   \ufffd        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 \u0026quot;could be exploited in a real world scenario.\u0026quot; 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\u0026apos;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\u0026apos;s still in use.\r\n\r\nReset fb to NULL once we\u0026apos;ve unreffed it to avoid doing it again\nuntil we\u0026apos;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\nteam: fix null-ptr-deref when team device type is changed\r\n\r\nGet a null-ptr-deref bug as follows with reproducer [1].\r\n\r\nBUG: kernel NULL pointer dereference, address: 0000000000000228\n...\nRIP: 0010:vlan_dev_hard_header+0x35/0x140 [8021q]\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __die+0x24/0x70\n ? page_fault_oops+0x82/0x150\n ? exc_page_fault+0x69/0x150\n ? asm_exc_page_fault+0x26/0x30\n ? vlan_dev_hard_header+0x35/0x140 [8021q]\n ? vlan_dev_hard_header+0x8e/0x140 [8021q]\n neigh_connected_output+0xb2/0x100\n ip6_finish_output2+0x1cb/0x520\n ? nf_hook_slow+0x43/0xc0\n ? ip6_mtu+0x46/0x80\n ip6_finish_output+0x2a/0xb0\n mld_sendpack+0x18f/0x250\n mld_ifc_work+0x39/0x160\n process_one_work+0x1e6/0x3f0\n worker_thread+0x4d/0x2f0\n ? __pfx_worker_thread+0x10/0x10\n kthread+0xe5/0x120\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x34/0x50\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1b/0x30\r\n\r\n[1]\n$ teamd -t team0 -d -c \u0026apos;{\u0026quot;runner\u0026quot;: {\u0026quot;name\u0026quot;: \u0026quot;loadbalance\u0026quot;}}\u0026apos;\n$ ip link add name t-dummy type dummy\n$ ip link add link t-dummy name t-dummy.100 type vlan id 100\n$ ip link add name t-nlmon type nlmon\n$ ip link set t-nlmon master team0\n$ ip link set t-nlmon nomaster\n$ ip link set t-dummy up\n$ ip link set team0 up\n$ ip link set t-dummy.100 down\n$ ip link set t-dummy.100 master team0\r\n\r\nWhen enslave a vlan device to team device and team device type is changed\nfrom non-ether to ether, header_ops of team device is changed to\nvlan_header_ops. That is incorrect and will trigger null-ptr-deref\nfor vlan-\u0026gt;real_dev in vlan_dev_hard_header() because team device is not\na vlan device.\r\n\r\nCache eth_header_ops in team_setup(), then assign cached header_ops to\nheader_ops of team net device when its type is changed from non-ether\nto ether to fix the bug.(CVE-2023-52574)\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\u0026apos;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-\u0026gt;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 \u0026lt;duration\u0026gt; -H \u0026apos;Connection: Close\u0026apos; \u0026lt;URL\u0026gt;\r\n\r\n- continuously dump SMC-D connections in parallel:\n  watch -n 1 \u0026apos;smcss -D\u0026apos;\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  \u0026lt;TASK\u0026gt;\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-\u0026gt;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-\u0026gt;timer could schedule the spu_dma_work and the\nspu_dma_work could also arm the dreamcastcard-\u0026gt;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-\u0026gt;channel)  |    schedule_work()\n                                 |  run_spu_dma() //worker\n  ...                            |    dreamcastcard-\u0026gt;channel-\u0026gt; //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 \u0026lt;TASK\u0026gt;\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)",
  "id": "OESA-2024-1496",
  "modified": "2026-08-06T11:06:56Z",
  "published": "2024-04-26T11:06:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1496"
    },
    {
      "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-52574"
    },
    {
      "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"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:P/AC:L/PR:H/UI:N/S:C/C:L/I:L/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2022-48627",
    "CVE-2022-48629",
    "CVE-2023-47233",
    "CVE-2023-52486",
    "CVE-2023-52504",
    "CVE-2023-52524",
    "CVE-2023-52574",
    "CVE-2023-52607",
    "CVE-2023-7042",
    "CVE-2024-24861",
    "CVE-2024-25739",
    "CVE-2024-26615",
    "CVE-2024-26654",
    "CVE-2024-26663",
    "CVE-2024-26696"
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.


Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.