huzaifas-sidhpurwala/security-commit huggingface dataset:
CVE-2024-47675: kernel: bpf: Fix use-after-free in bpf_uprobe_multi_link_attach()
Component: kernel
Severity: Moderate
CWE: CWE-416 (Use After Free)
CVSS v3: 6.7 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H)
Public date: 2024-10-21T00:00:00+00:00

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

bpf: Fix use-after-free in bpf_uprobe_multi_link_attach()

If bpf_link_prime() fails, bpf_uprobe_multi_link_attach() goes to the
error_free label and frees the array of bpf_uprobe's without calling
bpf_uprobe_unregister().

This leaks bpf_uprobe->uprobe and worse, this frees bpf_uprobe->consumer
without removing it from the uprobe->consumers list.

Statement: The default Red Hat Enterprise Linux kernel prevents unprivileged users from being able to use eBPF by the kernel.unprivileged_bpf_disabled sysctl. This would require a privileged user with CAP_SYS_ADMIN or root to be able to abuse this flaw reducing its attack space.

For the Red Hat Enterprise Linux 8 to confirm the current state, inspect the sysctl with the command:
~~~
# cat /proc/sys/kernel/unprivileged_bpf_disabled
~~~
The setting of 1 would mean that unprivileged users can not use eBPF, mitigating the flaw.

Affected upstream versions: 6.6
Fixed upstream versions: 0, 6.10.13, 6.11.2, 6.12, 6.6.54
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 790c630ab0e7d7aba6d186581d4627c09fce60f3
CVE-2024-47678: kernel: icmp: change the order of rate limits
Component: kernel
Severity: Moderate
CWE: CWE-203 (Observable Discrepancy)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N)
Public date: 2024-10-21T00:00:00+00:00

A flaw was found in the Linux kernel related to the order of rate limits for ICMP messages. The sequence in which rate limiters are applied potentially allows a side-channel attack, resulting in information disclosure.


Affected upstream versions: 3.18
Fixed upstream versions: 0, 6.1.113, 6.10.13, 6.11.2, 6.12, 6.6.54
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 997ba8889611891f91e8ad83583466aeab6239a3
CVE-2024-47679: kernel: vfs: fix race between evice_inodes() and find_inode()&#38;iput()
Component: kernel
Severity: Moderate
CWE: CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'))
CVSS v3: 4.7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-10-21T00:00:00+00:00

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

vfs: fix race between evice_inodes() and find_inode()&iput()

Hi, all

Recently I noticed a bug[1] in btrfs, after digged it into
and I believe it'a race in vfs.

Let's assume there's a inode (ie ino 261) with i_count 1 is
called by iput(), and there's a concurrent thread calling
generic_shutdown_super().

cpu0:                              cpu1:
iput() // i_count is 1
  ->spin_lock(inode)
  ->dec i_count to 0
  ->iput_final()                    generic_shutdown_super()
    ->__inode_add_lru()               ->evict_inodes()
      // cause some reason[2]           ->if (atomic_read(inode->i_count)) continue;
      // return before                  // inode 261 passed the above check
      // list_lru_add_obj()             // and then schedule out
   ->spin_unlock()
// note here: the inode 261
// was still at sb list and hash list,
// and I_FREEING|I_WILL_FREE was not been set

btrfs_iget()
  // after some function calls
  ->find_inode()
    // found the above inode 261
    ->spin_lock(inode)
   // check I_FREEING|I_WILL_FREE
   // and passed
      ->__iget()
    ->spin_unlock(inode)                // schedule back
                                        ->spin_lock(inode)
                                        // check (I_NEW|I_FREEING|I_WILL_FREE) flags,
                                        // passed and set I_FREEING
iput()                                  ->spin_unlock(inode)
  ->spin_lock(inode)			  ->evict()
  // dec i_count to 0
  ->iput_final()
    ->spin_unlock()
    ->evict()

Now, we have two threads simultaneously evicting
the same inode, which may trigger the BUG(inode->i_state & I_CLEAR)
statement both within clear_inode() and iput().

To fix the bug, recheck the inode->i_count after holding i_lock.
Because in the most scenarios, the first check is valid, and
the overhead of spin_lock() can be reduced.

If there is any misunderstanding, please let me know, thanks.

[1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/
[2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable()
return false when I reproduced the bug.


Affected upstream versions: 2.6.37
Fixed upstream versions: 0, 4.19.323, 5.10.227, 5.15.168, 5.4.285, 6.1.113, 6.10.13, 6.11.2, 6.12, 6.6.54
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 6cc13a80a26e6b48f78c725c01b91987d61563ef
CVE-2024-47685: kernel: netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put()
Component: kernel
Severity: Moderate
CWE: CWE-908 (Use of Uninitialized Resource)
CVSS v3: 6.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N)
Public date: 2024-10-21T00:00:00+00:00

A flaw was found in the Netfilter and IPV6 functionality in the Linux kernel leading to a leak of 4 random bits. This issue may allow a remote user to preform an unauthorized read of random bits from the server.

Statement: This issue is considered to be a moderate impact flaw, as the leaked data is a tcp stack and not the whole kernel. It does not seem to affect the availability. A remote user can potentially read 4 bits of random data from the server memory, but has no control of what is in the 4 bits and cannot bring any harm to the server from it.

Affected upstream versions: 3.18
Fixed upstream versions: 0, 4.19.323, 5.10.227, 5.15.168, 5.4.285, 6.1.113, 6.10.13, 6.11.2, 6.12, 6.6.54
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 872eca64c3267dbc5836b715716fc6c03a18eda7
CVE-2024-47692: kernel: nfsd: return -EINVAL when namelen is 0
Component: kernel
Severity: Moderate
CWE: CWE-476 (NULL Pointer Dereference)
CVSS v3: 6.5 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-10-21T00:00:00+00:00

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

nfsd: return -EINVAL when namelen is 0

When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may
result in namelen being 0, which will cause memdup_user() to return
ZERO_SIZE_PTR.
When we access the name.data that has been assigned the value of
ZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference is
triggered.

[ T1205] ==================================================================
[ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260
[ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205
[ T1205]
[ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406
[ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014
[ T1205] Call Trace:
[ T1205]  dump_stack+0x9a/0xd0
[ T1205]  ? nfs4_client_to_reclaim+0xe9/0x260
[ T1205]  __kasan_report.cold+0x34/0x84
[ T1205]  ? nfs4_client_to_reclaim+0xe9/0x260
[ T1205]  kasan_report+0x3a/0x50
[ T1205]  nfs4_client_to_reclaim+0xe9/0x260
[ T1205]  ? nfsd4_release_lockowner+0x410/0x410
[ T1205]  cld_pipe_downcall+0x5ca/0x760
[ T1205]  ? nfsd4_cld_tracking_exit+0x1d0/0x1d0
[ T1205]  ? down_write_killable_nested+0x170/0x170
[ T1205]  ? avc_policy_seqno+0x28/0x40
[ T1205]  ? selinux_file_permission+0x1b4/0x1e0
[ T1205]  rpc_pipe_write+0x84/0xb0
[ T1205]  vfs_write+0x143/0x520
[ T1205]  ksys_write+0xc9/0x170
[ T1205]  ? __ia32_sys_read+0x50/0x50
[ T1205]  ? ktime_get_coarse_real_ts64+0xfe/0x110
[ T1205]  ? ktime_get_coarse_real_ts64+0xa2/0x110
[ T1205]  do_syscall_64+0x33/0x40
[ T1205]  entry_SYSCALL_64_after_hwframe+0x67/0xd1
[ T1205] RIP: 0033:0x7fdbdb761bc7
[ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 514
[ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7
[ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008
[ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001
[ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b
[ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000
[ T1205] ==================================================================

Fix it by checking namelen.


Affected upstream versions: 5.2
Fixed upstream versions: 0, 5.10.227, 5.15.168, 5.4.285, 6.1.113, 6.10.13, 6.11.2, 6.12, 6.6.54
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 6d07040ae5c2214e39c7444d898039c9e655a79a
CVE-2024-47700: kernel: ext4: check stripe size compatibility on remount as well
Component: kernel
Severity: Moderate
CWE: CWE-369 (Divide By Zero)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-10-21T00:00:00+00:00

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

ext4: check stripe size compatibility on remount as well

We disable stripe size in __ext4_fill_super if it is not a multiple of
the cluster ratio however this check is missed when trying to remount.
This can leave us with cases where stripe < cluster_ratio after
remount:set making EXT4_B2C(sbi->s_stripe) become 0 that can cause some
unforeseen bugs like divide by 0.

Fix that by adding the check in remount path as well.


Affected upstream versions: 6.5
Fixed upstream versions: 0, 6.10.13, 6.11.2, 6.12, 6.6.54
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: faeff8b1ee2eaa5969c8e994d66c3337298cefed
CVE-2024-47703: kernel: bpf, lsm: Add check for BPF LSM return value
Component: kernel
Severity: Moderate
CWE: CWE-681 (Incorrect Conversion between Numeric Types)
CVSS v3: 4.4 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-10-21T00:00:00+00:00

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

bpf, lsm: Add check for BPF LSM return value

A bpf prog returning a positive number attached to file_alloc_security
hook makes kernel panic.

This happens because file system can not filter out the positive number
returned by the LSM prog using IS_ERR, and misinterprets this positive
number as a file pointer.

Given that hook file_alloc_security never returned positive number
before the introduction of BPF LSM, and other BPF LSM hooks may
encounter similar issues, this patch adds LSM return value check
in verifier, to ensure no unexpected value is returned.

Statement: The default Red Hat Enterprise Linux kernel prevents unprivileged users from being able to use eBPF by the kernel.unprivileged_bpf_disabled sysctl. This would require a privileged user with CAP_SYS_ADMIN or root to be able to abuse this flaw reducing its attack space.

For the Red Hat Enterprise Linux 9 to confirm the current state, inspect the sysctl with the command:

    cat /proc/sys/kernel/unprivileged_bpf_disabled

The setting of 1 would mean that unprivileged users can not use eBPF, mitigating the flaw.

Affected upstream versions: 5.7
Fixed upstream versions: 0, 6.10.13, 6.11.2, 6.12
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 1050727d83e70449991c29dd1cf29fe936a63da3
CVE-2024-47705: kernel: block: fix potential invalid pointer dereference in blk_add_partition
Component: kernel
Severity: Moderate
CWE: CWE-476 (NULL Pointer Dereference)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-10-21T00:00:00+00:00

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

block: fix potential invalid pointer dereference in blk_add_partition

The blk_add_partition() function initially used a single if-condition
(IS_ERR(part)) to check for errors when adding a partition. This was
modified to handle the specific case of -ENXIO separately, allowing the
function to proceed without logging the error in this case. However,
this change unintentionally left a path where md_autodetect_dev()
could be called without confirming that part is a valid pointer.

This commit separates the error handling logic by splitting the
initial if-condition, improving code readability and handling specific
error scenarios explicitly. The function now distinguishes the general
error case from -ENXIO without altering the existing behavior of
md_autodetect_dev() calls.


Affected upstream versions: 5.5
Fixed upstream versions: 0, 5.10.227, 5.15.168, 6.1.113, 6.10.13, 6.11.2, 6.12, 6.6.54
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 4bc4272e2506941c3f3d4fb8b0c659ee814dcf6f
CVE-2024-47706: kernel: block, bfq: fix possible UAF for bfqq->bic with merge chain
Component: kernel
Severity: Moderate
CWE: CWE-416 (Use After Free)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-10-21T00:00:00+00:00

A flaw was found in the Budget Fair Queueing (BFQ) I/O scheduler in the Linux kernel. Handling merged chains of BFQ queues can cause a use-after-free condition and result in a denial of service.


Affected upstream versions: 4.12
Fixed upstream versions: 0, 4.19.323, 5.10.227, 5.15.168, 5.4.285, 6.1.113, 6.10.13, 6.11.2, 6.12, 6.6.54
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: a9bdd5b36887d2bacb8bc777fd18317c99fc2587
CVE-2024-47710: kernel: sock_map: Add a cond_resched() in sock_hash_free()
Component: kernel
Severity: Moderate
CWE: CWE-400 (Uncontrolled Resource Consumption)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-10-21T00:00:00+00:00

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

sock_map: Add a cond_resched() in sock_hash_free()

Several syzbot soft lockup reports all have in common sock_hash_free()

If a map with a large number of buckets is destroyed, we need to yield
the cpu when needed.


Affected upstream versions: 5.4.49 < 5.4.285, 5.7.6 < 5.8, 5.8
Fixed upstream versions: 0, 5.10.227, 5.15.168, 5.4.285, 5.8, 6.1.113, 6.10.13, 6.11.2, 6.12, 6.6.54
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: bc05f6855642cff3c0eeb63060b35d8c4f8a851d
CVE-2024-47713: kernel: wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop()
Component: kernel
Severity: Moderate
CWE: CWE-664 (Improper Control of a Resource Through its Lifetime)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-10-21T00:00:00+00:00

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

wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop()

Since '__dev_queue_xmit()' should be called with interrupts enabled,
the following backtrace:

ieee80211_do_stop()
 ...
 spin_lock_irqsave(&local->queue_stop_reason_lock, flags)
 ...
 ieee80211_free_txskb()
  ieee80211_report_used_skb()
   ieee80211_report_ack_skb()
    cfg80211_mgmt_tx_status_ext()
     nl80211_frame_tx_status()
      genlmsg_multicast_netns()
       genlmsg_multicast_netns_filtered()
        nlmsg_multicast_filtered()
	 netlink_broadcast_filtered()
	  do_one_broadcast()
	   netlink_broadcast_deliver()
	    __netlink_sendskb()
	     netlink_deliver_tap()
	      __netlink_deliver_tap_skb()
	       dev_queue_xmit()
	        __dev_queue_xmit() ; with IRQS disabled
 ...
 spin_unlock_irqrestore(&local->queue_stop_reason_lock, flags)

issues the warning (as reported by syzbot reproducer):

WARNING: CPU: 2 PID: 5128 at kernel/softirq.c:362 __local_bh_enable_ip+0xc3/0x120

Fix this by implementing a two-phase skb reclamation in
'ieee80211_do_stop()', where actual work is performed
outside of a section with interrupts disabled.


Affected upstream versions: 2.6.32
Fixed upstream versions: 0, 4.19.323, 5.10.227, 5.15.168, 5.4.285, 6.1.113, 6.10.13, 6.11.2, 6.12, 6.6.54
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 07eb0bd7b0a8abed9d45e0f567c9af1dc83e5268
CVE-2024-47718: kernel: wifi: rtw88: always wait for both firmware loading attempts
Component: kernel
Severity: Moderate
CWE: CWE-416 (Use After Free)
CVSS v3: 4.4 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-10-21T00:00:00+00:00

A use-after-free flaw was found in the Linux kernel's mac80211-based wireless driver when firmware loading fails. This issue could allow a local user to crash the system as result of driver failure on an error path during power on.

Statement: The failure can only happen during boot (power on of specific hardware) and as result of failure for this hardware (on error path). As a result, the security impact is limited, for example, only for cases when a local user has full access to this hardware.

Affected upstream versions: 5.6
Fixed upstream versions: 0, 5.10.227, 5.15.168, 6.1.113, 6.10.13, 6.11.2, 6.12, 6.6.54
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: a0c1e2da652cf70825739bc12d49ea15805690bf
CVE-2024-47719: kernel: iommufd: Protect against overflow of ALIGN() during iova allocation
Component: kernel
Severity: Moderate
CWE: CWE-190 (Integer Overflow or Wraparound)
CVSS v3: 7.1 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H)
Public date: 2024-10-21T00:00:00+00:00

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

iommufd: Protect against overflow of ALIGN() during iova allocation

Userspace can supply an iova and uptr such that the target iova alignment
becomes really big and ALIGN() overflows which corrupts the selected area
range during allocation. CONFIG_IOMMUFD_TEST can detect this:

   WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/io_pagetable.c:268 iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [inline]
   WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/io_pagetable.c:268 iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352
   Modules linked in:
   CPU: 1 PID: 5092 Comm: syz-executor294 Not tainted 6.10.0-rc5-syzkaller-00294-g3ffea9a7a6f7 #0
   Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024
   RIP: 0010:iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [inline]
   RIP: 0010:iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352
   Code: fc e9 a4 f3 ff ff e8 1a 8b 4c fc 41 be e4 ff ff ff e9 8a f3 ff ff e8 0a 8b 4c fc 90 0f 0b 90 e9 37 f5 ff ff e8 fc 8a 4c fc 90 <0f> 0b 90 e9 68 f3 ff ff 48 c7 c1 ec 82 ad 8f 80 e1 07 80 c1 03 38
   RSP: 0018:ffffc90003ebf9e0 EFLAGS: 00010293
   RAX: ffffffff85499fa4 RBX: 00000000ffffffef RCX: ffff888079b49e00
   RDX: 0000000000000000 RSI: 00000000ffffffef RDI: 0000000000000000
   RBP: ffffc90003ebfc50 R08: ffffffff85499b30 R09: ffffffff85499942
   R10: 0000000000000002 R11: ffff888079b49e00 R12: ffff8880228e0010
   R13: 0000000000000000 R14: 1ffff920007d7f68 R15: ffffc90003ebfd00
   FS:  000055557d760380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000
   CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
   CR2: 00000000005fdeb8 CR3: 000000007404a000 CR4: 00000000003506f0
   DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
   DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
   Call Trace:
    <TASK>
    iommufd_ioas_copy+0x610/0x7b0 drivers/iommu/iommufd/ioas.c:274
    iommufd_fops_ioctl+0x4d9/0x5a0 drivers/iommu/iommufd/main.c:421
    vfs_ioctl fs/ioctl.c:51 [inline]
    __do_sys_ioctl fs/ioctl.c:907 [inline]
    __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893
    do_syscall_x64 arch/x86/entry/common.c:52 [inline]
    do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
    entry_SYSCALL_64_after_hwframe+0x77/0x7f

Cap the automatic alignment to the huge page size, which is probably a
better idea overall. Huge automatic alignments can fragment and chew up
the available IOVA space without any reason.


Affected upstream versions: 6.2
Fixed upstream versions: 0, 6.10.13, 6.11.2, 6.12, 6.6.54
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: cd6dd564ae7d99967ef50078216929418160b30e
CVE-2024-47727: kernel: x86/tdx: Fix "in-kernel MMIO" check
Component: kernel
Severity: Moderate
CWE: CWE-754 (Improper Check for Unusual or Exceptional Conditions)
CVSS v3: 7.8 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2024-10-21T00:00:00+00:00

A flaw was found in the Linux kernel. Userspace can deceive the kernel into performing MMIO (Memory-Mapped IO) operations in TDX (Trust Domain Extensions) on its behalf, allowing a #VE (Virtualization Exception) to be incorrectly handled as a in-kernel MMIO operation.

Statement: This flaw can only cause a denial of service by an attacker with normal privileges, limiting the impact of this vulnerability.
For this reason, this flaw has been rated with a moderate severity.

Affected upstream versions: 5.19
Fixed upstream versions: 0, 6.1.113, 6.10.13, 6.11.2, 6.12, 6.6.54
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 25703a3c980e21548774eea8c8a87a75c5c8f58c
CVE-2024-47737: kernel: nfsd: call cache_put if xdr_reserve_space returns NULL
Component: kernel
Severity: Moderate
CWE: CWE-401 (Missing Release of Memory after Effective Lifetime)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-10-21T00:00:00+00:00

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

nfsd: call cache_put if xdr_reserve_space returns NULL

If not enough buffer space available, but idmap_lookup has triggered
lookup_fn which calls cache_get and returns successfully. Then we
missed to call cache_put here which pairs with cache_get.

Reviwed-by: Jeff Layton <jlayton@kernel.org>


Affected upstream versions: 3.16
Fixed upstream versions: 0, 4.19.323, 5.10.227, 5.15.168, 5.4.285, 6.1.113, 6.10.13, 6.11.2, 6.12, 6.6.54
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 3e8081ebff12bec1347deaceb6bce0765cce54df
CVE-2024-47738: kernel: wifi: mac80211: don&#39;t use rate mask for offchannel TX either
Component: kernel
Severity: Moderate
CWE: CWE-755 (Improper Handling of Exceptional Conditions)
CVSS v3: 3.3 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L)
Public date: 2024-10-21T00:00:00+00:00

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

wifi: mac80211: don't use rate mask for offchannel TX either

Like the commit ab9177d83c04 ("wifi: mac80211: don't use rate mask for
scanning"), ignore incorrect settings to avoid no supported rate warning
reported by syzbot.

The syzbot did bisect and found cause is commit 9df66d5b9f45 ("cfg80211:
fix default HE tx bitrate mask in 2G band"), which however corrects
bitmask of HE MCS and recognizes correctly settings of empty legacy rate
plus HE MCS rate instead of returning -EINVAL.

As suggestions [1], follow the change of SCAN TX to consider this case of
offchannel TX as well.

[1] https://lore.kernel.org/linux-wireless/6ab2dc9c3afe753ca6fdcdd1421e7a1f47e87b84.camel@sipsolutions.net/T/#m2ac2a6d2be06a37c9c47a3d8a44b4f647ed4f024


Affected upstream versions: 5.10.51 < 5.11, 5.12.18 < 5.13, 5.13.3 < 5.14, 5.14
Fixed upstream versions: 0, 5.11, 5.13, 5.14, 6.1.113, 6.10.13, 6.11.2, 6.12, 6.6.54
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: aafca50e71dc8f3192a5bfb325135a7908f3ef9e