huzaifas-sidhpurwala/security-commit huggingface dataset:
CVE-2024-50109: kernel: md/raid10: fix null ptr dereference in raid10_size()
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-11-05T00:00:00+00:00

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

md/raid10: fix null ptr dereference in raid10_size()

In raid10_run() if raid10_set_queue_limits() succeed, the return value
is set to zero, and if following procedures failed raid10_run() will
return zero while mddev->private is still NULL, causing null ptr
dereference in raid10_size().

Fix the problem by only overwrite the return value if
raid10_set_queue_limits() failed.


Affected upstream versions: 6.9
Fixed upstream versions: 0, 6.11.6, 6.12
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: b3054db2fd2d35f2eb3b4b5fb1407792f465391c
CVE-2024-50110: kernel: xfrm: fix one more kernel-infoleak in algo dumping
Component: kernel
Severity: Moderate
CWE: CWE-908 (Use of Uninitialized Resource)
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-11-05T00:00:00+00:00

A vulnerability was found in the `xfrm` module in the Linux Kernel. This issue was discovered during fuzz testing, where uninitialized memory containing potentially sensitive data was inadvertently copied to user-space. This issue occurs when dumping IPsec algorithm data structures, exposing random padding from the structures. This issue could lead to information leaks if uninitialized memory is accessed by user-space applications.

Statement: This vulnerability is considered moderate severity. While it involves the leakage of uninitialized kernel memory, it requires specific conditions to be exploited. The information leaked consists of random padding within data structures, which is less likely to contain critical information compared to more sensitive kernel data, such as encryption keys or user credentials.

Affected upstream versions: 5.11
Fixed upstream versions: 0, 5.15.170, 6.1.115, 6.11.6, 6.12, 6.6.59
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 610d4cea9b442b22b4820695fc3335e64849725e
CVE-2024-50115: kernel: KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory
Component: kernel
Severity: Moderate
CWE: CWE-125 (Out-of-bounds Read)
CVSS v3: 4.7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N)
Public date: 2024-11-05T00:00:00+00:00

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

KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory

Ignore nCR3[4:0] when loading PDPTEs from memory for nested SVM, as bits
4:0 of CR3 are ignored when PAE paging is used, and thus VMRUN doesn't
enforce 32-byte alignment of nCR3.

In the absolute worst case scenario, failure to ignore bits 4:0 can result
in an out-of-bounds read, e.g. if the target page is at the end of a
memslot, and the VMM isn't using guard pages.

Per the APM:

  The CR3 register points to the base address of the page-directory-pointer
  table. The page-directory-pointer table is aligned on a 32-byte boundary,
  with the low 5 address bits 4:0 assumed to be 0.

And the SDM's much more explicit:

  4:0    Ignored

Note, KVM gets this right when loading PDPTRs, it's only the nSVM flow
that is broken.


Affected upstream versions: 3.2
Fixed upstream versions: 0, 5.10.229, 5.15.170, 6.1.115, 6.11.6, 6.12, 6.6.59
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 76ce386feb14ec9a460784fcd495d8432acce7a5
CVE-2024-50117: kernel: drm/amd: Guard against bad data for ATIF ACPI method
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-11-05T00:00:00+00:00

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

drm/amd: Guard against bad data for ATIF ACPI method

If a BIOS provides bad data in response to an ATIF method call
this causes a NULL pointer dereference in the caller.

```
? show_regs (arch/x86/kernel/dumpstack.c:478 (discriminator 1))
? __die (arch/x86/kernel/dumpstack.c:423 arch/x86/kernel/dumpstack.c:434)
? page_fault_oops (arch/x86/mm/fault.c:544 (discriminator 2) arch/x86/mm/fault.c:705 (discriminator 2))
? do_user_addr_fault (arch/x86/mm/fault.c:440 (discriminator 1) arch/x86/mm/fault.c:1232 (discriminator 1))
? acpi_ut_update_object_reference (drivers/acpi/acpica/utdelete.c:642)
? exc_page_fault (arch/x86/mm/fault.c:1542)
? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623)
? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:387 (discriminator 2)) amdgpu
? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:386 (discriminator 1)) amdgpu
```

It has been encountered on at least one system, so guard for it.

(cherry picked from commit c9b7c809b89f24e9372a4e7f02d64c950b07fdee)


Affected upstream versions: 4.2
Fixed upstream versions: 0, 4.19.323, 5.10.229, 5.15.170, 5.4.285, 6.1.115, 6.11.6, 6.12, 6.6.59
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 58556dcbd5606a5daccaee73b2130bc16b48e025
CVE-2024-50120: kernel: smb: client: Handle kstrdup failures for passwords
Component: kernel
Severity: Low
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-11-05T00:00:00+00:00

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

smb: client: Handle kstrdup failures for passwords

In smb3_reconfigure(), after duplicating ctx->password and
ctx->password2 with kstrdup(), we need to check for allocation
failures.

If ses->password allocation fails, return -ENOMEM.
If ses->password2 allocation fails, free ses->password, set it
to NULL, and return -ENOMEM.

Statement: The bug could happen when system already out of memory (that should not happen for Linux), so considering it as low level security impact.

Affected upstream versions: 6.6.24 < 6.6.59, 6.7.12 < 6.8, 6.8.3 < 6.9, 6.9
Fixed upstream versions: 0, 6.11.6, 6.12, 6.6.59, 6.8, 6.9
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 35dbac8c328d6afe937cd45ecd41d209d0b9f8b8
CVE-2024-50124: kernel: Bluetooth: ISO: Fix UAF on iso_sock_timeout
Component: kernel
Severity: Moderate
CWE: CWE-416 (Use After Free)
CVSS v3: 5.7 (CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-11-05T17:10:52.434000+00:00

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

Bluetooth: ISO: Fix UAF on iso_sock_timeout

conn->sk maybe have been unlinked/freed while waiting for iso_conn_lock
so this checks if the conn->sk is still valid by checking if it part of
iso_sk_list.


Affected upstream versions: 6.0
Fixed upstream versions: 0, 6.1.115, 6.11.6, 6.12, 6.6.59
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 876ac72d535fa94f4ac57bba651987c6f990f646
CVE-2024-50125: kernel: Bluetooth: SCO: Fix UAF on sco_sock_timeout
Component: kernel
Severity: Moderate
CWE: CWE-416 (Use After Free)
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-11-05T00:00:00+00:00

A use-after-free vulnerability was found in the Linux kernel's Bluetooth SCO. When sco_sock_timeout() is called, conn->sk may be unlinked/freed while waiting for sco_conn_lock. This checks if the conn->sk is still valid by checking if it is part of
sco_sk_list, leading to a loss of availability and system confidentiality.


Affected upstream versions: 4.14.263 < 4.15, 4.19.207 < 4.20, 5.4.148 < 5.5, 5.10.67 < 5.11, 5.13.19 < 5.14, 5.14.6 < 5.15, 5.15
Fixed upstream versions: 0, 4.15, 4.20, 5.11, 5.14, 5.15, 5.15.181, 5.5, 6.1.115, 6.11.6, 6.12, 6.6.59
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 74a466a15731a754bcd8b5a83c126b5122e15a45
CVE-2024-50126: kernel: net: sched: use RCU read-side critical section in taprio_dump()
Component: kernel
Severity: Moderate
CWE: CWE-416 (Use After Free)
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-11-05T00:00:00+00:00

A use-after-free vulnerability was found in the taprio_dump() function in the Linux kernel.


Affected upstream versions: 6.1
Fixed upstream versions: 0, 6.1.117, 6.11.6, 6.12, 6.6.59
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: b911fa9e92ee586e36479ad57b88f20471acaca1
CVE-2024-50127: kernel: net: sched: fix use-after-free in taprio_change()
Component: kernel
Severity: Moderate
CWE: CWE-416 (Use After Free)
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2024-11-05T00:00:00+00:00

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

net: sched: fix use-after-free in taprio_change()

In 'taprio_change()', 'admin' pointer may become dangling due to sched
switch / removal caused by 'advance_sched()', and critical section
protected by 'q->current_entry_lock' is too small to prevent from such
a scenario (which causes use-after-free detected by KASAN). Fix this
by prefer 'rcu_replace_pointer()' over 'rcu_assign_pointer()' to update
'admin' immediately before an attempt to schedule freeing.

Statement: The config param CONFIG_NET_SCH_TAPRIO enabled only for latest versions of Red Hat Enterprise Linux 9 (as a module). Issue could happen only for specific usage of taprio (for example tc qdisc taprio) and only if debug enabled (with KASAN). The potential attack complexity is high. Will be fixed in affected versions of Red Hat Enterprise Linux.

Affected upstream versions: 5.2
Fixed upstream versions: 0, 5.10.229, 5.15.170, 5.4.285, 6.1.115, 6.11.6, 6.12, 6.6.59
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 2f868ce6013548a713c431c679ef73747a66fcf3
CVE-2024-50130: kernel: netfilter: bpf: must hold reference on net namespace
Component: kernel
Severity: Low
CWE: CWE-416 (Use After Free)
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-11-05T00:00:00+00:00

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

netfilter: bpf: must hold reference on net namespace

BUG: KASAN: slab-use-after-free in __nf_unregister_net_hook+0x640/0x6b0
Read of size 8 at addr ffff8880106fe400 by task repro/72=
bpf_nf_link_release+0xda/0x1e0
bpf_link_free+0x139/0x2d0
bpf_link_release+0x68/0x80
__fput+0x414/0xb60

Eric says:
 It seems that bpf was able to defer the __nf_unregister_net_hook()
 after exit()/close() time.
 Perhaps a netns reference is missing, because the netns has been
 dismantled/freed already.
 bpf_nf_link_attach() does :
 link->net = net;
 But I do not see a reference being taken on net.

Add such a reference and release it after hook unreg.
Note that I was unable to get syzbot reproducer to work, so I
do not know if this resolves this splat.

Statement: The config param CONFIG_NETFILTER_BPF_LINK disabled everywhere, so not actual for all versions of Red Hat Enterprise Linux.

Affected upstream versions: 6.4
Fixed upstream versions: 0, 6.11.6, 6.12, 6.6.59
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: f41bd93b3e0508edc7ba820357f949071dcc0acc
CVE-2024-50141: kernel: ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context
Component: kernel
Severity: Moderate
CWE: CWE-99 (Improper Control of Resource Identifiers ('Resource Injection'))
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-11-07T00:00:00+00:00

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

ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context

PRMT needs to find the correct type of block to translate the PA-VA
mapping for EFI runtime services.

The issue arises because the PRMT is finding a block of type
EFI_CONVENTIONAL_MEMORY, which is not appropriate for runtime services
as described in Section 2.2.2 (Runtime Services) of the UEFI
Specification [1]. Since the PRM handler is a type of runtime service,
this causes an exception when the PRM handler is called.

    [Firmware Bug]: Unable to handle paging request in EFI runtime service
    WARNING: CPU: 22 PID: 4330 at drivers/firmware/efi/runtime-wrappers.c:341
        __efi_queue_work+0x11c/0x170
    Call trace:

Let PRMT find a block with EFI_MEMORY_RUNTIME for PRM handler and PRM
context.

If no suitable block is found, a warning message will be printed, but
the procedure continues to manage the next PRM handler.

However, if the PRM handler is actually called without proper allocation,
it would result in a failure during error handling.

By using the correct memory types for runtime services, ensure that the
PRM handler and the context are properly mapped in the virtual address
space during runtime, preventing the paging request error.

The issue is really that only memory that has been remapped for runtime
by the firmware can be used by the PRM handler, and so the region needs
to have the EFI_MEMORY_RUNTIME attribute.

[ rjw: Subject and changelog edits ]


Affected upstream versions: 5.14
Fixed upstream versions: 0, 5.15.171, 6.1.115, 6.11.6, 6.12, 6.6.59
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 8df52929530839e878e6912e33348b54101e3250
CVE-2024-50142: kernel: xfrm: validate new SA&#39;s prefixlen using SA family when sel.family is unset
Component: kernel
Severity: Moderate
CWE: CWE-20 (Improper Input Validation)
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-11-07T00:00:00+00:00

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

xfrm: validate new SA's prefixlen using SA family when sel.family is unset

This expands the validation introduced in commit 07bf7908950a ("xfrm:
Validate address prefix lengths in the xfrm selector.")

syzbot created an SA with
    usersa.sel.family = AF_UNSPEC
    usersa.sel.prefixlen_s = 128
    usersa.family = AF_INET

Because of the AF_UNSPEC selector, verify_newsa_info doesn't put
limits on prefixlen_{s,d}. But then copy_from_user_state sets
x->sel.family to usersa.family (AF_INET). Do the same conversion in
verify_newsa_info before validating prefixlen_{s,d}, since that's how
prefixlen is going to be used later on.


Affected upstream versions: 2.6.12
Fixed upstream versions: 0, 4.19.323, 5.10.229, 5.15.170, 5.4.285, 6.1.115, 6.11.6, 6.12, 6.6.59
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: f31398570acf0f0804c644006f7bfa9067106b0a
CVE-2024-50143: kernel: udf: fix uninit-value use in udf_get_fileshortad
Component: kernel
Severity: Moderate
CWE: CWE-908 (Use of Uninitialized Resource)
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2024-11-07T00:00:00+00:00

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

udf: fix uninit-value use in udf_get_fileshortad

Check for overflow when computing alen in udf_current_aext to mitigate
later uninit-value use in udf_get_fileshortad KMSAN bug[1].
After applying the patch reproducer did not trigger any issue[2].

[1] https://syzkaller.appspot.com/bug?extid=8901c4560b7ab5c2f9df
[2] https://syzkaller.appspot.com/x/log.txt?x=10242227980000

Statement: The bug could happen only if udf file system being used. It would be hard to use it for attack, because uninitialized variable being read in udf_get_fileshortad only visible with KMSAN (KASAN debugging) enabled.

Affected upstream versions: 2.6.12
Fixed upstream versions: 0, 4.19.323, 5.10.246, 5.15.170, 5.4.285, 6.1.115, 6.11.6, 6.12, 6.6.59
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 5eb76fb98b3335aa5cca6a7db2e659561c79c32b
CVE-2024-50148: kernel: Bluetooth: bnep: fix wild-memory-access in proto_unregister
Component: kernel
Severity: Low
CWE: CWE-459 (Incomplete Cleanup)
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-11-07T00:00:00+00:00

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

Bluetooth: bnep: fix wild-memory-access in proto_unregister

There's issue as follows:
  KASAN: maybe wild-memory-access in range [0xdead...108-0xdead...10f]
  CPU: 3 UID: 0 PID: 2805 Comm: rmmod Tainted: G        W
  RIP: 0010:proto_unregister+0xee/0x400
  Call Trace:
   <TASK>
   __do_sys_delete_module+0x318/0x580
   do_syscall_64+0xc1/0x1d0
   entry_SYSCALL_64_after_hwframe+0x77/0x7f

As bnep_init() ignore bnep_sock_init()'s return value, and bnep_sock_init()
will cleanup all resource. Then when remove bnep module will call
bnep_sock_cleanup() to cleanup sock's resource.
To solve above issue just return bnep_sock_init()'s return value in
bnep_exit().


Affected upstream versions: 2.6.12
Fixed upstream versions: 0, 4.19.323, 5.10.229, 5.15.170, 5.4.285, 6.1.115, 6.11.6, 6.12, 6.6.59
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: e232728242c4e98fb30e4c6bedb6ba8b482b6301
CVE-2024-50151: kernel: smb: client: fix OOBs when building SMB2_IOCTL request
Component: kernel
Severity: Moderate
CWE: CWE-787 (Out-of-bounds Write)
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-11-07T00:00:00+00:00

A flaw was found in the cifs module in the Linux kernel. When building SMB2_IOCTL requests using encryption, either enforced by the server or using the 'seal' mount option, an out-of-bounds write can be triggered when the user passes an input buffer greater than 328 bytes, resulting in memory corruption and a kernel crash.

Statement: To exploit this flaw, an attacker needs local access to the system and SMB encryption must be enabled, limiting the impact of this issue. For these reasons, this flaw has been rated with a moderate severity.

The cifs module in the Linux kernel as shipped in Red Hat Enterprise Linux 8 is not affected by this vulnerability because the vulnerable code was introduced in a newer version of the Linux kernel.

Affected upstream versions: 5.0
Fixed upstream versions: 0, 5.10.229, 5.15.170, 5.4.285, 6.1.115, 6.11.6, 6.12, 6.6.59
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 6f0516ef1290da24b85461ed08a0938af7415e49
CVE-2024-50152: kernel: smb: client: fix possible double free in smb2_set_ea()
Component: kernel
Severity: Moderate
CWE: CWE-415 (Double 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-11-07T00:00:00+00:00

A doubly freeing memory vulnerability exists in the Linux kernel smb client. After the first successful memory allocation for 'ea', the second memory release for 'ea' will result in double free, leading to loss of availability of the system.


Affected upstream versions: 6.6.32 < 6.6.59, 6.8
Fixed upstream versions: 0, 6.11.6, 6.12, 6.6.59
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: b1813c220b76f60b1727984794377c4aa849d4c1
CVE-2024-50153: kernel: scsi: target: core: Fix null-ptr-deref in target_alloc_device()
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-11-07T00:00:00+00:00

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

scsi: target: core: Fix null-ptr-deref in target_alloc_device()

There is a null-ptr-deref issue reported by KASAN:

BUG: KASAN: null-ptr-deref in target_alloc_device+0xbc4/0xbe0 [target_core_mod]
...
 kasan_report+0xb9/0xf0
 target_alloc_device+0xbc4/0xbe0 [target_core_mod]
 core_dev_setup_virtual_lun0+0xef/0x1f0 [target_core_mod]
 target_core_init_configfs+0x205/0x420 [target_core_mod]
 do_one_initcall+0xdd/0x4e0
...
 entry_SYSCALL_64_after_hwframe+0x76/0x7e

In target_alloc_device(), if allocing memory for dev queues fails, then
dev will be freed by dev->transport->free_device(), but dev->transport
is not initialized at that time, which will lead to a null pointer
reference problem.

Fixing this bug by freeing dev with hba->backend->ops->free_device().


Affected upstream versions: 5.10.180 < 5.10.229, 5.11
Fixed upstream versions: 0, 5.10.229, 5.15.170, 6.1.115, 6.11.6, 6.12, 6.6.59
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 8c1e6717f60d31f8af3937c23c4f1498529584e1
CVE-2024-50154: kernel: tcp/dccp: Don&#39;t use timer_pending() in reqsk_queue_unlink().
Component: kernel
Severity: Moderate
CWE: CWE-416 (Use After Free)
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2024-11-07T00:00:00+00:00

A use-after-free (UAF) vulnerability was found and fixed in the Linux kernel's TCP subsystem related to request socket (reqsk) timers during handshake handling. This issue stems from a race condition caused by relying on `timer_pending()` in `reqsk_queue_unlink()`. This could result in the timer continuing to run after the socket (`req->sk`) is freed, allowing BPF programs to access invalid memory.

Statement: This vulnerability is classified as moderate severity rather than important because the issue primarily affects a narrow set of conditions, notably when BPF programs are involved in tracing TCP retransmissions. In most scenarios, the reqsk timer is pinned and the race condition is unlikely to be triggered. Additionally, the problem only occurs if the request socket (`req->sk`) is closed while the timer is still pending, which is an uncommon sequence of events. While the potential for a use-after-free (UAF) exists, it requires specific timing and conditions to exploit, limiting its overall risk and impact on typical systems.

Affected upstream versions: 4.1.11 < 4.2, 4.2
Fixed upstream versions: 0, 4.2, 5.10.237, 5.15.170, 5.4.293, 6.1.115, 6.11.6, 6.12, 6.6.59
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 106e457953315e476b3642ef24be25ed862aaba3
CVE-2024-50163: kernel: bpf: Make sure internal and UAPI bpf_redirect flags don't overlap
Component: kernel
Severity: Low
CWE: CWE-20 (Improper Input Validation)
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-11-07T00:00:00+00:00

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

bpf: Make sure internal and UAPI bpf_redirect flags don't overlap

The bpf_redirect_info is shared between the SKB and XDP redirect paths,
and the two paths use the same numeric flag values in the ri->flags
field (specifically, BPF_F_BROADCAST == BPF_F_NEXTHOP). This means that
if skb bpf_redirect_neigh() is used with a non-NULL params argument and,
subsequently, an XDP redirect is performed using the same
bpf_redirect_info struct, the XDP path will get confused and end up
crashing, which syzbot managed to trigger.

With the stack-allocated bpf_redirect_info, the structure is no longer
shared between the SKB and XDP paths, so the crash doesn't happen
anymore. However, different code paths using identically-numbered flag
values in the same struct field still seems like a bit of a mess, so
this patch cleans that up by moving the flag definitions together and
redefining the three flags in BPF_F_REDIRECT_INTERNAL to not overlap
with the flags used for XDP. It also adds a BUILD_BUG_ON() check to make
sure the overlap is not re-introduced by mistake.

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.14
Fixed upstream versions: 0, 5.15.170, 6.1.115, 6.11.6, 6.12, 6.6.59
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 4e1e428533845d48828bd3875c0e92e8565b9962