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

OESA-2024-2184 (CVE-2024-44965)

Vulnerability from osv_openeuler – Published: 2024-09-27 11:07 – Updated: 2026-08-06 11:07 – 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:

x86/mm: Fix pti_clone_pgtable() alignment assumption

Guenter reported dodgy crashes on an i386-nosmp build using GCC-11 that had the form of endless traps until entry stack exhaust and then

DF from the stack guard.

It turned out that pti_clone_pgtable() had alignment assumptions on the start address, notably it hard assumes start is PMD aligned. This is true on x86_64, but very much not true on i386.

These assumptions can cause the end condition to malfunction, leading to a 'short' clone. Guess what happens when the user mapping has a short copy of the entry text?

Use the correct increment form for addr to avoid alignment assumptions.(CVE-2024-44965)

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

gtp: pull network headers in gtp_dev_xmit()

syzbot/KMSAN reported use of uninit-value in get_dev_xmit() [1]

We must make sure the IPv4 or Ipv6 header is pulled in skb->head before accessing fields in them.

Use pskb_inet_may_pull() to fix this issue.

[1] BUG: KMSAN: uninit-value in ipv6_pdp_find drivers/net/gtp.c:220 [inline] BUG: KMSAN: uninit-value in gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline] BUG: KMSAN: uninit-value in gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281 ipv6_pdp_find drivers/net/gtp.c:220 [inline] gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline] gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281 __netdev_start_xmit include/linux/netdevice.h:4913 [inline] netdev_start_xmit include/linux/netdevice.h:4922 [inline] xmit_one net/core/dev.c:3580 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3596 __dev_queue_xmit+0x358c/0x5610 net/core/dev.c:4423 dev_queue_xmit include/linux/netdevice.h:3105 [inline] packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3145 [inline] packet_sendmsg+0x90e3/0xa3a0 net/packet/af_packet.c:3177 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212 x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Uninit was created at: slab_post_alloc_hook mm/slub.c:3994 [inline] slab_alloc_node mm/slub.c:4037 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4080 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:583 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:674 alloc_skb include/linux/skbuff.h:1320 [inline] alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6526 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2815 packet_alloc_skb net/packet/af_packet.c:2994 [inline] packet_snd net/packet/af_packet.c:3088 [inline] packet_sendmsg+0x749c/0xa3a0 net/packet/af_packet.c:3177 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212 x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f

CPU: 0 UID: 0 PID: 7115 Comm: syz.1.515 Not tainted 6.11.0-rc1-syzkaller-00043-g94ede2a3e913 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024(CVE-2024-44999)

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

Input: MT - limit max slots

syzbot is reporting too large allocation at input_mt_init_slots(), for num_slots is supplied from userspace using ioctl(UI_DEV_CREATE).

Since nobody knows possible max slots, this patch chose 1024.(CVE-2024-45008)

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

fix bitmap corruption on close_range() with CLOSE_RANGE_UNSHARE

copy_fd_bitmaps(new, old, count) is expected to copy the first count/BITS_PER_LONG bits from old->full_fds_bits[] and fill the rest with zeroes. What it does is copying enough words (BITS_TO_LONGS(count/BITS_PER_LONG)), then memsets the rest. That works fine, if all bits past the cutoff point are clear. Otherwise we are risking garbage from the last word we'd copied.

For most of the callers that is true - expand_fdtable() has count equal to old->max_fds, so there's no open descriptors past count, let alone fully occupied words in ->open_fds[], which is what bits in ->full_fds_bits[] correspond to.

The other caller (dup_fd()) passes sane_fdtable_size(old_fdt, max_fds), which is the smallest multiple of BITS_PER_LONG that covers all opened descriptors below max_fds. In the common case (copying on fork()) max_fds is ~0U, so all opened descriptors will be below it and we are fine, by the same reasons why the call in expand_fdtable() is safe.

Unfortunately, there is a case where max_fds is less than that and where we might, indeed, end up with junk in ->full_fds_bits[] - close_range(from, to, CLOSE_RANGE_UNSHARE) with * descriptor table being currently shared * 'to' being above the current capacity of descriptor table * 'from' being just under some chunk of opened descriptors. In that case we end up with observably wrong behaviour - e.g. spawn a child with CLONE_FILES, get all descriptors in range 0..127 open, then close_range(64, ~0U, CLOSE_RANGE_UNSHARE) and watch dup(0) ending up with descriptor #128, despite #64 being observably not open.

The minimally invasive fix would be to deal with that in dup_fd(). If this proves to add measurable overhead, we can go that way, but let's try to fix copy_fd_bitmaps() first.

  • new helper: bitmap_copy_and_expand(to, from, bits_to_copy, size).
  • make copy_fd_bitmaps() take the bitmap size in words, rather than bits; it's 'count' argument is always a multiple of BITS_PER_LONG, so we are not losing any information, and that way we can use the same helper for all three bitmaps - compiler will see that count is a multiple of BITS_PER_LONG for the large ones, so it'll generate plain memcpy()+memset().

Reproducer added to tools/testing/selftests/core/close_range_test.c(CVE-2024-45025)

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

mmc: mmc_test: Fix NULL dereference on allocation failure

If the "test->highmem = alloc_pages()" allocation fails then calling __free_pages(test->highmem) will result in a NULL dereference. Also change the error code to -ENOMEM instead of returning success.(CVE-2024-45028)

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

drm/amdgpu: fix ucode out-of-bounds read warning

Clear warning that read ucode[] may out-of-bounds.(CVE-2024-46723)

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

Squashfs: sanity check symbolic link size

Syzkiller reports a "KMSAN: uninit-value in pick_link" bug.

This is caused by an uninitialised page, which is ultimately caused by a corrupted symbolic link size read from disk.

The reason why the corrupted symlink size causes an uninitialised page is due to the following sequence of events:

  1. squashfs_read_inode() is called to read the symbolic link from disk. This assigns the corrupted value 3875536935 to inode->i_size.

  2. Later squashfs_symlink_read_folio() is called, which assigns this corrupted value to the length variable, which being a signed int, overflows producing a negative number.

  3. The following loop that fills in the page contents checks that the copied bytes is less than length, which being negative means the loop is skipped, producing an uninitialised page.

This patch adds a sanity check which checks that the symbolic link size is not larger than expected.

--

V2: fix spelling mistake.(CVE-2024-46744)

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

Input: uinput - reject requests with unreasonable number of slots

When exercising uinput interface syzkaller may try setting up device with a really large number of slots, which causes memory allocation failure in input_mt_init_slots(). While this allocation failure is handled properly and request is rejected, it results in syzkaller reports. Additionally, such request may put undue burden on the system which will try to free a lot of memory for a bogus request.

Fix it by limiting allowed number of slots to 100. This can easily be extended if we see devices that can track more than 100 contacts.(CVE-2024-46745)

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

HID: cougar: fix slab-out-of-bounds Read in cougar_report_fixup

report_fixup for the Cougar 500k Gaming Keyboard was not verifying that the report descriptor size was correct before accessing it(CVE-2024-46747)

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

wifi: mwifiex: Do not return unused priv in mwifiex_get_priv_by_id()

mwifiex_get_priv_by_id() returns the priv pointer corresponding to the bss_num and bss_type, but without checking if the priv is actually currently in use. Unused priv pointers do not have a wiphy attached to them which can lead to NULL pointer dereferences further down the callstack. Fix this by returning only used priv pointers which have priv->bss_mode set to something else than NL80211_IFTYPE_UNSPECIFIED.

Said NULL pointer dereference happened when an Accesspoint was started with wpa_supplicant -i mlan0 with this config:

network={ ssid="somessid" mode=2 frequency=2412 key_mgmt=WPA-PSK WPA-PSK-SHA256 proto=RSN group=CCMP pairwise=CCMP psk="12345678" }

When waiting for the AP to be established, interrupting wpa_supplicant with <ctrl-c> and starting it again this happens:

| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000140 | Mem abort info: | ESR = 0x0000000096000004 | EC = 0x25: DABT (current EL), IL = 32 bits | SET = 0, FnV = 0 | EA = 0, S1PTW = 0 | FSC = 0x04: level 0 translation fault | Data abort info: | ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 | CM = 0, WnR = 0, TnD = 0, TagAccess = 0 | GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 | user pgtable: 4k pages, 48-bit VAs, pgdp=0000000046d96000 | [0000000000000140] pgd=0000000000000000, p4d=0000000000000000 | Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP | Modules linked in: caam_jr caamhash_desc spidev caamalg_desc crypto_engine authenc libdes mwifiex_sdio +mwifiex crct10dif_ce cdc_acm onboard_usb_hub fsl_imx8_ddr_perf imx8m_ddrc rtc_ds1307 lm75 rtc_snvs +imx_sdma caam imx8mm_thermal spi_imx error imx_cpufreq_dt fuse ip_tables x_tables ipv6 | CPU: 0 PID: 8 Comm: kworker/0:1 Not tainted 6.9.0-00007-g937242013fce-dirty #18 | Hardware name: somemachine (DT) | Workqueue: events sdio_irq_work | pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : mwifiex_get_cfp+0xd8/0x15c [mwifiex] | lr : mwifiex_get_cfp+0x34/0x15c [mwifiex] | sp : ffff8000818b3a70 | x29: ffff8000818b3a70 x28: ffff000006bfd8a5 x27: 0000000000000004 | x26: 000000000000002c x25: 0000000000001511 x24: 0000000002e86bc9 | x23: ffff000006bfd996 x22: 0000000000000004 x21: ffff000007bec000 | x20: 000000000000002c x19: 0000000000000000 x18: 0000000000000000 | x17: 000000040044ffff x16: 00500072b5503510 x15: ccc283740681e517 | x14: 0201000101006d15 x13: 0000000002e8ff43 x12: 002c01000000ffb1 | x11: 0100000000000000 x10: 02e8ff43002c0100 x9 : 0000ffb100100157 | x8 : ffff000003d20000 x7 : 00000000000002f1 x6 : 00000000ffffe124 | x5 : 0000000000000001 x4 : 0000000000000003 x3 : 0000000000000000 | x2 : 0000000000000000 x1 : 0001000000011001 x0 : 0000000000000000 | Call trace: | mwifiex_get_cfp+0xd8/0x15c [mwifiex] | mwifiex_parse_single_response_buf+0x1d0/0x504 [mwifiex] | mwifiex_handle_event_ext_scan_report+0x19c/0x2f8 [mwifiex] | mwifiex_process_sta_event+0x298/0xf0c [mwifiex] | mwifiex_process_event+0x110/0x238 [mwifiex] | mwifiex_main_process+0x428/0xa44 [mwifiex] | mwifiex_sdio_interrupt+0x64/0x12c [mwifiex_sdio] | process_sdio_pending_irqs+0x64/0x1b8 | sdio_irq_work+0x4c/0x7c | process_one_work+0x148/0x2a0 | worker_thread+0x2fc/0x40c | kthread+0x110/0x114 | ret_from_fork+0x10/0x20 | Code: a94153f3 a8c37bfd d50323bf d65f03c0 (f940a000) | ---[ end trace 0000000000000000 ]---(CVE-2024-46755)

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

hwmon: (adc128d818) Fix underflows seen when writing limit attributes

DIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large negative number such as -9223372036854775808 is provided by the user. Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.(CVE-2024-46759)

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

sch/netem: fix use after free in netem_dequeue

If netem_dequeue() enqueues packet to inner qdisc and that qdisc returns __NET_XMIT_STOLEN. The packet is dropped but qdisc_tree_reduce_backlog() is not called to update the parent's q.qlen, leading to the similar use-after-free as Commit e04991a48dbaf382 ("netem: fix return value if duplicate enqueue fails")

Commands to trigger KASAN UaF:

ip link add type dummy ip link set lo up ip link set dummy0 up tc qdisc add dev lo parent root handle 1: drr tc filter add dev lo parent 1: basic classid 1:1 tc class add dev lo classid 1:1 drr tc qdisc add dev lo parent 1:1 handle 2: netem tc qdisc add dev lo parent 2: handle 3: drr tc filter add dev lo parent 3: basic classid 3:1 action mirred egress redirect dev dummy0 tc class add dev lo classid 3:1 drr ping -c1 -W0.01 localhost # Trigger bug tc class del dev lo classid 1:1 tc class add dev lo classid 1:1 drr ping -c1 -W0.01 localhost # UaF(CVE-2024-46800)

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
To clipboard 

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-4.19.90-2409.6.0.0297.oe2003sp4.aarch64.rpm",
          "bpftool-debuginfo-4.19.90-2409.6.0.0297.oe2003sp4.aarch64.rpm",
          "kernel-4.19.90-2409.6.0.0297.oe2003sp4.aarch64.rpm",
          "kernel-debuginfo-4.19.90-2409.6.0.0297.oe2003sp4.aarch64.rpm",
          "kernel-debugsource-4.19.90-2409.6.0.0297.oe2003sp4.aarch64.rpm",
          "kernel-devel-4.19.90-2409.6.0.0297.oe2003sp4.aarch64.rpm",
          "kernel-source-4.19.90-2409.6.0.0297.oe2003sp4.aarch64.rpm",
          "kernel-tools-4.19.90-2409.6.0.0297.oe2003sp4.aarch64.rpm",
          "kernel-tools-debuginfo-4.19.90-2409.6.0.0297.oe2003sp4.aarch64.rpm",
          "kernel-tools-devel-4.19.90-2409.6.0.0297.oe2003sp4.aarch64.rpm",
          "perf-4.19.90-2409.6.0.0297.oe2003sp4.aarch64.rpm",
          "perf-debuginfo-4.19.90-2409.6.0.0297.oe2003sp4.aarch64.rpm",
          "python2-perf-4.19.90-2409.6.0.0297.oe2003sp4.aarch64.rpm",
          "python2-perf-debuginfo-4.19.90-2409.6.0.0297.oe2003sp4.aarch64.rpm",
          "python3-perf-4.19.90-2409.6.0.0297.oe2003sp4.aarch64.rpm",
          "python3-perf-debuginfo-4.19.90-2409.6.0.0297.oe2003sp4.aarch64.rpm"
        ],
        "src": [
          "kernel-4.19.90-2409.6.0.0297.oe2003sp4.src.rpm"
        ],
        "x86_64": [
          "bpftool-4.19.90-2409.6.0.0297.oe2003sp4.x86_64.rpm",
          "bpftool-debuginfo-4.19.90-2409.6.0.0297.oe2003sp4.x86_64.rpm",
          "kernel-4.19.90-2409.6.0.0297.oe2003sp4.x86_64.rpm",
          "kernel-debuginfo-4.19.90-2409.6.0.0297.oe2003sp4.x86_64.rpm",
          "kernel-debugsource-4.19.90-2409.6.0.0297.oe2003sp4.x86_64.rpm",
          "kernel-devel-4.19.90-2409.6.0.0297.oe2003sp4.x86_64.rpm",
          "kernel-source-4.19.90-2409.6.0.0297.oe2003sp4.x86_64.rpm",
          "kernel-tools-4.19.90-2409.6.0.0297.oe2003sp4.x86_64.rpm",
          "kernel-tools-debuginfo-4.19.90-2409.6.0.0297.oe2003sp4.x86_64.rpm",
          "kernel-tools-devel-4.19.90-2409.6.0.0297.oe2003sp4.x86_64.rpm",
          "perf-4.19.90-2409.6.0.0297.oe2003sp4.x86_64.rpm",
          "perf-debuginfo-4.19.90-2409.6.0.0297.oe2003sp4.x86_64.rpm",
          "python2-perf-4.19.90-2409.6.0.0297.oe2003sp4.x86_64.rpm",
          "python2-perf-debuginfo-4.19.90-2409.6.0.0297.oe2003sp4.x86_64.rpm",
          "python3-perf-4.19.90-2409.6.0.0297.oe2003sp4.x86_64.rpm",
          "python3-perf-debuginfo-4.19.90-2409.6.0.0297.oe2003sp4.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:20.03-LTS-SP4",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.19.90-2409.6.0.0297.oe2003sp4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nx86/mm: Fix pti_clone_pgtable() alignment assumption\r\n\r\nGuenter reported dodgy crashes on an i386-nosmp build using GCC-11\nthat had the form of endless traps until entry stack exhaust and then\n#DF from the stack guard.\r\n\r\nIt turned out that pti_clone_pgtable() had alignment assumptions on\nthe start address, notably it hard assumes start is PMD aligned. This\nis true on x86_64, but very much not true on i386.\r\n\r\nThese assumptions can cause the end condition to malfunction, leading\nto a \u0026apos;short\u0026apos; clone. Guess what happens when the user mapping has a\nshort copy of the entry text?\r\n\r\nUse the correct increment form for addr to avoid alignment\nassumptions.(CVE-2024-44965)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngtp: pull network headers in gtp_dev_xmit()\r\n\r\nsyzbot/KMSAN reported use of uninit-value in get_dev_xmit() [1]\r\n\r\nWe must make sure the IPv4 or Ipv6 header is pulled in skb-\u0026gt;head\nbefore accessing fields in them.\r\n\r\nUse pskb_inet_may_pull() to fix this issue.\r\n\r\n[1]\nBUG: KMSAN: uninit-value in ipv6_pdp_find drivers/net/gtp.c:220 [inline]\n BUG: KMSAN: uninit-value in gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline]\n BUG: KMSAN: uninit-value in gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281\n  ipv6_pdp_find drivers/net/gtp.c:220 [inline]\n  gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline]\n  gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281\n  __netdev_start_xmit include/linux/netdevice.h:4913 [inline]\n  netdev_start_xmit include/linux/netdevice.h:4922 [inline]\n  xmit_one net/core/dev.c:3580 [inline]\n  dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3596\n  __dev_queue_xmit+0x358c/0x5610 net/core/dev.c:4423\n  dev_queue_xmit include/linux/netdevice.h:3105 [inline]\n  packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276\n  packet_snd net/packet/af_packet.c:3145 [inline]\n  packet_sendmsg+0x90e3/0xa3a0 net/packet/af_packet.c:3177\n  sock_sendmsg_nosec net/socket.c:730 [inline]\n  __sock_sendmsg+0x30f/0x380 net/socket.c:745\n  __sys_sendto+0x685/0x830 net/socket.c:2204\n  __do_sys_sendto net/socket.c:2216 [inline]\n  __se_sys_sendto net/socket.c:2212 [inline]\n  __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212\n  x64_sys_call+0x3799/0x3c10 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\r\n\r\nUninit was created at:\n  slab_post_alloc_hook mm/slub.c:3994 [inline]\n  slab_alloc_node mm/slub.c:4037 [inline]\n  kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4080\n  kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:583\n  __alloc_skb+0x363/0x7b0 net/core/skbuff.c:674\n  alloc_skb include/linux/skbuff.h:1320 [inline]\n  alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6526\n  sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2815\n  packet_alloc_skb net/packet/af_packet.c:2994 [inline]\n  packet_snd net/packet/af_packet.c:3088 [inline]\n  packet_sendmsg+0x749c/0xa3a0 net/packet/af_packet.c:3177\n  sock_sendmsg_nosec net/socket.c:730 [inline]\n  __sock_sendmsg+0x30f/0x380 net/socket.c:745\n  __sys_sendto+0x685/0x830 net/socket.c:2204\n  __do_sys_sendto net/socket.c:2216 [inline]\n  __se_sys_sendto net/socket.c:2212 [inline]\n  __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212\n  x64_sys_call+0x3799/0x3c10 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\r\n\r\nCPU: 0 UID: 0 PID: 7115 Comm: syz.1.515 Not tainted 6.11.0-rc1-syzkaller-00043-g94ede2a3e913 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024(CVE-2024-44999)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nInput: MT - limit max slots\r\n\r\nsyzbot is reporting too large allocation at input_mt_init_slots(), for\nnum_slots is supplied from userspace using ioctl(UI_DEV_CREATE).\r\n\r\nSince nobody knows possible max slots, this patch chose 1024.(CVE-2024-45008)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfix bitmap corruption on close_range() with CLOSE_RANGE_UNSHARE\r\n\r\ncopy_fd_bitmaps(new, old, count) is expected to copy the first\ncount/BITS_PER_LONG bits from old-\u0026gt;full_fds_bits[] and fill\nthe rest with zeroes.  What it does is copying enough words\n(BITS_TO_LONGS(count/BITS_PER_LONG)), then memsets the rest.\nThat works fine, *if* all bits past the cutoff point are\nclear.  Otherwise we are risking garbage from the last word\nwe\u0026apos;d copied.\r\n\r\nFor most of the callers that is true - expand_fdtable() has\ncount equal to old-\u0026gt;max_fds, so there\u0026apos;s no open descriptors\npast count, let alone fully occupied words in -\u0026gt;open_fds[],\nwhich is what bits in -\u0026gt;full_fds_bits[] correspond to.\r\n\r\nThe other caller (dup_fd()) passes sane_fdtable_size(old_fdt, max_fds),\nwhich is the smallest multiple of BITS_PER_LONG that covers all\nopened descriptors below max_fds.  In the common case (copying on\nfork()) max_fds is ~0U, so all opened descriptors will be below\nit and we are fine, by the same reasons why the call in expand_fdtable()\nis safe.\r\n\r\nUnfortunately, there is a case where max_fds is less than that\nand where we might, indeed, end up with junk in -\u0026gt;full_fds_bits[] -\nclose_range(from, to, CLOSE_RANGE_UNSHARE) with\n\t* descriptor table being currently shared\n\t* \u0026apos;to\u0026apos; being above the current capacity of descriptor table\n\t* \u0026apos;from\u0026apos; being just under some chunk of opened descriptors.\nIn that case we end up with observably wrong behaviour - e.g. spawn\na child with CLONE_FILES, get all descriptors in range 0..127 open,\nthen close_range(64, ~0U, CLOSE_RANGE_UNSHARE) and watch dup(0) ending\nup with descriptor #128, despite #64 being observably not open.\r\n\r\nThe minimally invasive fix would be to deal with that in dup_fd().\nIf this proves to add measurable overhead, we can go that way, but\nlet\u0026apos;s try to fix copy_fd_bitmaps() first.\r\n\r\n* new helper: bitmap_copy_and_expand(to, from, bits_to_copy, size).\n* make copy_fd_bitmaps() take the bitmap size in words, rather than\nbits; it\u0026apos;s \u0026apos;count\u0026apos; argument is always a multiple of BITS_PER_LONG,\nso we are not losing any information, and that way we can use the\nsame helper for all three bitmaps - compiler will see that count\nis a multiple of BITS_PER_LONG for the large ones, so it\u0026apos;ll generate\nplain memcpy()+memset().\r\n\r\nReproducer added to tools/testing/selftests/core/close_range_test.c(CVE-2024-45025)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmmc: mmc_test: Fix NULL dereference on allocation failure\r\n\r\nIf the \u0026quot;test-\u0026gt;highmem = alloc_pages()\u0026quot; allocation fails then calling\n__free_pages(test-\u0026gt;highmem) will result in a NULL dereference.  Also\nchange the error code to -ENOMEM instead of returning success.(CVE-2024-45028)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: fix ucode out-of-bounds read warning\r\n\r\nClear warning that read ucode[] may out-of-bounds.(CVE-2024-46723)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nSquashfs: sanity check symbolic link size\r\n\r\nSyzkiller reports a \u0026quot;KMSAN: uninit-value in pick_link\u0026quot; bug.\r\n\r\nThis is caused by an uninitialised page, which is ultimately caused\nby a corrupted symbolic link size read from disk.\r\n\r\nThe reason why the corrupted symlink size causes an uninitialised\npage is due to the following sequence of events:\r\n\r\n1. squashfs_read_inode() is called to read the symbolic\n   link from disk.  This assigns the corrupted value\n   3875536935 to inode-\u0026gt;i_size.\r\n\r\n2. Later squashfs_symlink_read_folio() is called, which assigns\n   this corrupted value to the length variable, which being a\n   signed int, overflows producing a negative number.\r\n\r\n3. The following loop that fills in the page contents checks that\n   the copied bytes is less than length, which being negative means\n   the loop is skipped, producing an uninitialised page.\r\n\r\nThis patch adds a sanity check which checks that the symbolic\nlink size is not larger than expected.\r\n\r\n--\r\n\r\nV2: fix spelling mistake.(CVE-2024-46744)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nInput: uinput - reject requests with unreasonable number of slots\r\n\r\n\nWhen exercising uinput interface syzkaller may try setting up device\nwith a really large number of slots, which causes memory allocation\nfailure in input_mt_init_slots(). While this allocation failure is\nhandled properly and request is rejected, it results in syzkaller\nreports. Additionally, such request may put undue burden on the\nsystem which will try to free a lot of memory for a bogus request.\r\n\r\nFix it by limiting allowed number of slots to 100. This can easily\nbe extended if we see devices that can track more than 100 contacts.(CVE-2024-46745)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nHID: cougar: fix slab-out-of-bounds Read in cougar_report_fixup\r\n\r\nreport_fixup for the Cougar 500k Gaming Keyboard was not verifying\nthat the report descriptor size was correct before accessing it(CVE-2024-46747)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: mwifiex: Do not return unused priv in mwifiex_get_priv_by_id()\r\n\r\nmwifiex_get_priv_by_id() returns the priv pointer corresponding to\nthe bss_num and bss_type, but without checking if the priv is actually\ncurrently in use.\nUnused priv pointers do not have a wiphy attached to them which can\nlead to NULL pointer dereferences further down the callstack.  Fix\nthis by returning only used priv pointers which have priv-\u0026gt;bss_mode\nset to something else than NL80211_IFTYPE_UNSPECIFIED.\r\n\r\nSaid NULL pointer dereference happened when an Accesspoint was started\nwith wpa_supplicant -i mlan0 with this config:\r\n\r\nnetwork={\n        ssid=\u0026quot;somessid\u0026quot;\n        mode=2\n        frequency=2412\n        key_mgmt=WPA-PSK WPA-PSK-SHA256\n        proto=RSN\n        group=CCMP\n        pairwise=CCMP\n        psk=\u0026quot;12345678\u0026quot;\n}\r\n\r\nWhen waiting for the AP to be established, interrupting wpa_supplicant\nwith \u0026lt;ctrl-c\u0026gt; and starting it again this happens:\r\n\r\n| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000140\n| Mem abort info:\n|   ESR = 0x0000000096000004\n|   EC = 0x25: DABT (current EL), IL = 32 bits\n|   SET = 0, FnV = 0\n|   EA = 0, S1PTW = 0\n|   FSC = 0x04: level 0 translation fault\n| Data abort info:\n|   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n|   CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n|   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n| user pgtable: 4k pages, 48-bit VAs, pgdp=0000000046d96000\n| [0000000000000140] pgd=0000000000000000, p4d=0000000000000000\n| Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP\n| Modules linked in: caam_jr caamhash_desc spidev caamalg_desc crypto_engine authenc libdes mwifiex_sdio\n+mwifiex crct10dif_ce cdc_acm onboard_usb_hub fsl_imx8_ddr_perf imx8m_ddrc rtc_ds1307 lm75 rtc_snvs\n+imx_sdma caam imx8mm_thermal spi_imx error imx_cpufreq_dt fuse ip_tables x_tables ipv6\n| CPU: 0 PID: 8 Comm: kworker/0:1 Not tainted 6.9.0-00007-g937242013fce-dirty #18\n| Hardware name: somemachine (DT)\n| Workqueue: events sdio_irq_work\n| pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n| pc : mwifiex_get_cfp+0xd8/0x15c [mwifiex]\n| lr : mwifiex_get_cfp+0x34/0x15c [mwifiex]\n| sp : ffff8000818b3a70\n| x29: ffff8000818b3a70 x28: ffff000006bfd8a5 x27: 0000000000000004\n| x26: 000000000000002c x25: 0000000000001511 x24: 0000000002e86bc9\n| x23: ffff000006bfd996 x22: 0000000000000004 x21: ffff000007bec000\n| x20: 000000000000002c x19: 0000000000000000 x18: 0000000000000000\n| x17: 000000040044ffff x16: 00500072b5503510 x15: ccc283740681e517\n| x14: 0201000101006d15 x13: 0000000002e8ff43 x12: 002c01000000ffb1\n| x11: 0100000000000000 x10: 02e8ff43002c0100 x9 : 0000ffb100100157\n| x8 : ffff000003d20000 x7 : 00000000000002f1 x6 : 00000000ffffe124\n| x5 : 0000000000000001 x4 : 0000000000000003 x3 : 0000000000000000\n| x2 : 0000000000000000 x1 : 0001000000011001 x0 : 0000000000000000\n| Call trace:\n|  mwifiex_get_cfp+0xd8/0x15c [mwifiex]\n|  mwifiex_parse_single_response_buf+0x1d0/0x504 [mwifiex]\n|  mwifiex_handle_event_ext_scan_report+0x19c/0x2f8 [mwifiex]\n|  mwifiex_process_sta_event+0x298/0xf0c [mwifiex]\n|  mwifiex_process_event+0x110/0x238 [mwifiex]\n|  mwifiex_main_process+0x428/0xa44 [mwifiex]\n|  mwifiex_sdio_interrupt+0x64/0x12c [mwifiex_sdio]\n|  process_sdio_pending_irqs+0x64/0x1b8\n|  sdio_irq_work+0x4c/0x7c\n|  process_one_work+0x148/0x2a0\n|  worker_thread+0x2fc/0x40c\n|  kthread+0x110/0x114\n|  ret_from_fork+0x10/0x20\n| Code: a94153f3 a8c37bfd d50323bf d65f03c0 (f940a000)\n| ---[ end trace 0000000000000000 ]---(CVE-2024-46755)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhwmon: (adc128d818) Fix underflows seen when writing limit attributes\r\n\r\nDIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large\nnegative number such as -9223372036854775808 is provided by the user.\nFix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.(CVE-2024-46759)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsch/netem: fix use after free in netem_dequeue\r\n\r\nIf netem_dequeue() enqueues packet to inner qdisc and that qdisc\nreturns __NET_XMIT_STOLEN. The packet is dropped but\nqdisc_tree_reduce_backlog() is not called to update the parent\u0026apos;s\nq.qlen, leading to the similar use-after-free as Commit\ne04991a48dbaf382 (\u0026quot;netem: fix return value if duplicate enqueue\nfails\u0026quot;)\r\n\r\nCommands to trigger KASAN UaF:\r\n\r\nip link add type dummy\nip link set lo up\nip link set dummy0 up\ntc qdisc add dev lo parent root handle 1: drr\ntc filter add dev lo parent 1: basic classid 1:1\ntc class add dev lo classid 1:1 drr\ntc qdisc add dev lo parent 1:1 handle 2: netem\ntc qdisc add dev lo parent 2: handle 3: drr\ntc filter add dev lo parent 3: basic classid 3:1 action mirred egress\nredirect dev dummy0\ntc class add dev lo classid 3:1 drr\nping -c1 -W0.01 localhost # Trigger bug\ntc class del dev lo classid 1:1\ntc class add dev lo classid 1:1 drr\nping -c1 -W0.01 localhost # UaF(CVE-2024-46800)",
  "id": "OESA-2024-2184",
  "modified": "2026-08-06T11:07:39Z",
  "published": "2024-09-27T11:07:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2184"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44965"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44999"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45008"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45025"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45028"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46723"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46744"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46745"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46747"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46755"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46759"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46800"
    }
  ],
  "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-44965",
    "CVE-2024-44999",
    "CVE-2024-45008",
    "CVE-2024-45025",
    "CVE-2024-45028",
    "CVE-2024-46723",
    "CVE-2024-46744",
    "CVE-2024-46745",
    "CVE-2024-46747",
    "CVE-2024-46755",
    "CVE-2024-46759",
    "CVE-2024-46800"
  ]
}



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.