huzaifas-sidhpurwala/security-commit huggingface dataset:
CVE-2024-50044: kernel: Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change
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-10-21T00:00:00+00:00

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

Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change

rfcomm_sk_state_change attempts to use sock_lock so it must never be
called with it locked but rfcomm_sock_ioctl always attempt to lock it
causing the following trace:

======================================================
WARNING: possible circular locking dependency detected
6.8.0-syzkaller-08951-gfe46a7dd189e #0 Not tainted
------------------------------------------------------
syz-executor386/5093 is trying to acquire lock:
ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1671 [inline]
ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73

but task is already holding lock:
ffff88807badfd28 (&d->lock){+.+.}-{3:3}, at: __rfcomm_dlc_close+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491

Statement: Only lock warning or similar possible, so security impact is limited.

Affected upstream versions: 2.6.27
Fixed upstream versions: 0, 4.19.323, 5.10.227, 5.15.168, 5.4.285, 6.1.113, 6.11.4, 6.12, 6.6.57
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: b77b3fb12fd483cae7c28648903b1d8a6b275f01
CVE-2024-50055: kernel: driver core: bus: Fix double free in driver API bus_register()
Component: kernel
Severity: Moderate
CWE: CWE-415 (Double 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:

driver core: bus: Fix double free in driver API bus_register()

For bus_register(), any error which happens after kset_register() will
cause that @priv are freed twice, fixed by setting @priv with NULL after
the first free.

Statement: This issue is considered to be a moderate impact flaw, as the exploitation for this will need an ADMIN (or ROOT) privilege (PR:H).

Affected upstream versions: 6.3
Fixed upstream versions: 0, 6.11.4, 6.12, 6.6.57
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: d885c464c25018b81a6b58f5d548fc2e3ef87dd1
CVE-2024-50057: kernel: usb: typec: tipd: Free IRQ only if it was requested before
Component: kernel
Severity: Moderate
CWE: CWE-763 (Release of Invalid Pointer or Reference)
CVSS v3: 0 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:N)
Public date: 2024-10-21T00:00:00+00:00

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

usb: typec: tipd: Free IRQ only if it was requested before

In polling mode, if no IRQ was requested there is no need to free it.
Call devm_free_irq() only if client->irq is set. This fixes the warning
caused by the tps6598x module removal:

WARNING: CPU: 2 PID: 333 at kernel/irq/devres.c:144 devm_free_irq+0x80/0x8c
...
...
Call trace:
  devm_free_irq+0x80/0x8c
  tps6598x_remove+0x28/0x88 [tps6598x]
  i2c_device_remove+0x2c/0x9c
  device_remove+0x4c/0x80
  device_release_driver_internal+0x1cc/0x228
  driver_detach+0x50/0x98
  bus_remove_driver+0x6c/0xbc
  driver_unregister+0x30/0x60
  i2c_del_driver+0x54/0x64
  tps6598x_i2c_driver_exit+0x18/0xc3c [tps6598x]
  __arm64_sys_delete_module+0x184/0x264
  invoke_syscall+0x48/0x110
  el0_svc_common.constprop.0+0xc8/0xe8
  do_el0_svc+0x20/0x2c
  el0_svc+0x28/0x98
  el0t_64_sync_handler+0x13c/0x158
  el0t_64_sync+0x190/0x194

Statement: This issue does not seems to be a security flaw.

Affected upstream versions: 4.15
Fixed upstream versions: 0, 6.11.4, 6.12, 6.6.57
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: b72bf5cade51ba4055c8a8998d275e72e6b521ce
CVE-2024-50058: kernel: serial: protect uart_port_dtr_rts() in uart_shutdown() too
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:

serial: protect uart_port_dtr_rts() in uart_shutdown() too

Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part
3) added few uport == NULL checks. It added one to uart_shutdown(), so
the commit assumes, uport can be NULL in there. But right after that
protection, there is an unprotected "uart_port_dtr_rts(uport, false);"
call. That is invoked only if HUPCL is set, so I assume that is the
reason why we do not see lots of these reports.

Or it cannot be NULL at this point at all for some reason :P.

Until the above is investigated, stay on the safe side and move this
dereference to the if too.

I got this inconsistency from Coverity under CID 1585130. Thanks.


Affected upstream versions: 4.7
Fixed upstream versions: 0, 5.10.229, 5.15.170, 6.1.115, 6.11.4, 6.12, 6.6.57
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 2fe399bb8efd0d325ab1138cf8e3ecf23a39e96d
CVE-2024-50060: kernel: io_uring: check if we need to reschedule during overflow flush
Component: kernel
Severity: Moderate
CWE: CWE-667 (Improper Locking)
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:

io_uring: check if we need to reschedule during overflow flush

In terms of normal application usage, this list will always be empty.
And if an application does overflow a bit, it'll have a few entries.
However, nothing obviously prevents syzbot from running a test case
that generates a ton of overflow entries, and then flushing them can
take quite a while.

Check for needing to reschedule while flushing, and drop our locks and
do so if necessary. There's no state to maintain here as overflows
always prune from head-of-list, hence it's fine to drop and reacquire
the locks at the end of the loop.


Affected upstream versions: 5.1
Fixed upstream versions: 0, 6.1.113, 6.11.4, 6.12, 6.6.57
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: a2493904e95ce94bbec819d8f7f03b99976eb25c
CVE-2024-50064: kernel: zram: free secondary algorithms names
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:

zram: free secondary algorithms names

We need to kfree() secondary algorithms names when reset zram device that
had multi-streams, otherwise we leak memory.

[senozhatsky@chromium.org: kfree(NULL) is legal]


Affected upstream versions: 6.2
Fixed upstream versions: 0, 6.11.4, 6.12, 6.6.57
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 6272936fd242ca1f784c3e21596dfb3859dff276
CVE-2024-50067: kernel: uprobe: avoid out-of-bounds memory access of fetching args
Component: kernel
Severity: Moderate
CWE: CWE-787 (Out-of-bounds Write)
CVSS v3: 7.3 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:H)
Public date: 2024-10-28T00:00:00+00:00

An out-of-bounds overflow vulnerability was found in the Linux kernel. When Uprobe needs to fetch args into a per-CPU buffer and then copy to a ring buffer, sometimes user-space strings and arrays can be very large, but the size of the per-CPU buffer is only page size and checking is not performed, so an overflow can occur. This can result in a loss of confidentiality, availability, and integrity


Affected upstream versions: 3.14
Fixed upstream versions: 0, 6.1.118, 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: 0dc3ad9ad2188da7f090b3dbe4d2fcd9ae8ae64f
CVE-2024-50073: kernel: tty: n_gsm: Fix use-after-free in gsm_cleanup_mux
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-29T00:00:00+00:00

A user after free vulnerability exists in the linux kernel such that when gsm_cleanup_mux is called,the gsm_msg on the tx_ctrl_list is not freed,resulting in loss of availability of the system.


Affected upstream versions: 5.15.209 < 5.16, 5.18.18 < 5.19, 5.19.2 < 5.20, 6.0
Fixed upstream versions: 0, 5.16, 5.19, 5.20, 6.1.114, 6.11.5, 6.12, 6.6.58
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: bf171b5e86e41de4c1cf32fb7aefa275c3d7de49
CVE-2024-50074: kernel: parport: Proper fix for array out-of-bounds access
Component: kernel
Severity: Moderate
CWE: CWE-125 (Out-of-bounds Read)
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-29T00:00:00+00:00

An out-of-bounds array access memory flaw was found in the Linux kernel. When snprintf() returns the would-be-printed size, not the actual output size, the length
calculation can still go over the given limit and cause an overflow, resulting in loss of availability of the system.

Statement: This vulnerability cannot be exploited to cause more than a denial of service, which is why the CVSS has been rated as such by Red Hat.

Affected upstream versions: 4.19.320 < 4.19.323, 5.4.282 < 5.4.285, 5.10.224 < 5.10.228, 5.15.165 < 5.15.169, 6.1.103 < 6.1.114, 6.6.44 < 6.6.58, 6.10.3 < 6.11, 6.11
Fixed upstream versions: 0, 4.19.323, 5.10.228, 5.15.169, 5.4.285, 6.1.114, 6.11, 6.11.5, 6.12, 6.6.58
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 8aadef73ba3b325704ed5cfc4696a25c350182cf
CVE-2024-50075: kernel: xhci: tegra: fix checked USB2 port number
Component: kernel
Severity: Moderate
CWE: CWE-119 (Improper Restriction of Operations within the Bounds of a Memory Buffer)
CVSS v3: 6 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:H)
Public date: 2024-10-29T00:00:00+00:00

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

xhci: tegra: fix checked USB2 port number

If USB virtualizatoin is enabled, USB2 ports are shared between all
Virtual Functions. The USB2 port number owned by an USB2 root hub in
a Virtual Function may be less than total USB2 phy number supported
by the Tegra XUSB controller.

Using total USB2 phy number as port number to check all PORTSC values
would cause invalid memory access.

[  116.923438] Unable to handle kernel paging request at virtual address 006c622f7665642f
...
[  117.213640] Call trace:
[  117.216783]  tegra_xusb_enter_elpg+0x23c/0x658
[  117.222021]  tegra_xusb_runtime_suspend+0x40/0x68
[  117.227260]  pm_generic_runtime_suspend+0x30/0x50
[  117.232847]  __rpm_callback+0x84/0x3c0
[  117.237038]  rpm_suspend+0x2dc/0x740
[  117.241229] pm_runtime_work+0xa0/0xb8
[  117.245769]  process_scheduled_works+0x24c/0x478
[  117.251007]  worker_thread+0x23c/0x328
[  117.255547]  kthread+0x104/0x1b0
[  117.259389]  ret_from_fork+0x10/0x20
[  117.263582] Code: 54000222 f9461ae8 f8747908 b4ffff48 (f9400100)


Affected upstream versions: 6.3
Fixed upstream versions: 0, 6.11.5, 6.12, 6.6.58
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 9c696bf4ab54c7cec81221887564305f0ceeac0a
CVE-2024-50076: kernel: vt: prevent kernel-infoleak in con_font_get()
Component: kernel
Severity: Moderate
CWE: CWE-909 (Missing Initialization of Resource)
CVSS v3: 6.5 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N)
Public date: 2024-10-29T00:00:00+00:00

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

vt: prevent kernel-infoleak in con_font_get()

font.data may not initialize all memory spaces depending on the implementation
of vc->vc_sw->con_font_get. This may cause info-leak, so to prevent this, it
is safest to modify it to initialize the allocated memory space to 0, and it
generally does not affect the overall performance of the system.


Affected upstream versions: 2.6.12
Fixed upstream versions: 0, 4.19.323, 5.10.229, 5.15.171, 5.4.285, 6.1.116, 6.11.5, 6.12, 6.6.58
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: efc67cee700b89ffbdb74a0603a083ec1290ae31
CVE-2024-50077: kernel: Bluetooth: ISO: Fix multiple init when debugfs is disabled
Component: kernel
Severity: Moderate
CWE: CWE-665 (Improper Initialization)
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-29T00:00:00+00:00

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

Bluetooth: ISO: Fix multiple init when debugfs is disabled

If bt_debugfs is not created successfully, which happens if either
CONFIG_DEBUG_FS or CONFIG_DEBUG_FS_ALLOW_ALL is unset, then iso_init()
returns early and does not set iso_inited to true. This means that a
subsequent call to iso_init() will result in duplicate calls to
proto_register(), bt_sock_register(), etc.

With CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, the
duplicate call to proto_register() triggers this BUG():

  list_add double add: new=ffffffffc0b280d0, prev=ffffffffbab56250,
    next=ffffffffc0b280d0.
  ------------[ cut here ]------------
  kernel BUG at lib/list_debug.c:35!
  Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI
  CPU: 2 PID: 887 Comm: bluetoothd Not tainted 6.10.11-1-ao-desktop #1
  RIP: 0010:__list_add_valid_or_report+0x9a/0xa0
  ...
    __list_add_valid_or_report+0x9a/0xa0
    proto_register+0x2b5/0x340
    iso_init+0x23/0x150 [bluetooth]
    set_iso_socket_func+0x68/0x1b0 [bluetooth]
    kmem_cache_free+0x308/0x330
    hci_sock_sendmsg+0x990/0x9e0 [bluetooth]
    __sock_sendmsg+0x7b/0x80
    sock_write_iter+0x9a/0x110
    do_iter_readv_writev+0x11d/0x220
    vfs_writev+0x180/0x3e0
    do_writev+0xca/0x100
  ...

This change removes the early return. The check for iso_debugfs being
NULL was unnecessary, it is always NULL when iso_inited is false.


Affected upstream versions: 6.0
Fixed upstream versions: 0, 6.1.114, 6.11.5, 6.12, 6.6.58
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: fa4b832c5a6ec35023a1b997cf658c436619c752
CVE-2024-50078: kernel: Bluetooth: Call iso_exit() on module unload
Component: kernel
Severity: Moderate
CWE: CWE-787 (Out-of-bounds Write)
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-29T00:00:00+00:00

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

Bluetooth: Call iso_exit() on module unload

If iso_init() has been called, iso_exit() must be called on module
unload. Without that, the struct proto that iso_init() registered with
proto_register() becomes invalid, which could cause unpredictable
problems later. In my case, with CONFIG_LIST_HARDENED and
CONFIG_BUG_ON_DATA_CORRUPTION enabled, loading the module again usually
triggers this BUG():

  list_add corruption. next->prev should be prev (ffffffffb5355fd0),
    but was 0000000000000068. (next=ffffffffc0a010d0).
  ------------[ cut here ]------------
  kernel BUG at lib/list_debug.c:29!
  Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI
  CPU: 1 PID: 4159 Comm: modprobe Not tainted 6.10.11-4+bt2-ao-desktop #1
  RIP: 0010:__list_add_valid_or_report+0x61/0xa0
  ...
    __list_add_valid_or_report+0x61/0xa0
    proto_register+0x299/0x320
    hci_sock_init+0x16/0xc0 [bluetooth]
    bt_init+0x68/0xd0 [bluetooth]
    __pfx_bt_init+0x10/0x10 [bluetooth]
    do_one_initcall+0x80/0x2f0
    do_init_module+0x8b/0x230
    __do_sys_init_module+0x15f/0x190
    do_syscall_64+0x68/0x110
  ...

Statement: The bug happens only when admin unloads and then loads again Bluetooth kernel module, so impact is limited.

Affected upstream versions: 6.0
Fixed upstream versions: 0, 6.1.114, 6.11.5, 6.12, 6.6.58
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 4af7ba39a1a02e16ee8cd0d3b6c6657f51b8ad7a
CVE-2024-50081: kernel: blk-mq: setup queue -&gt;tag_set before initializing hctx
Component: kernel
Severity: Moderate
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-10-29T00:00:00+00:00

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

blk-mq: setup queue ->tag_set before initializing hctx

Commit 7b815817aa58 ("blk-mq: add helper for checking if one CPU is mapped to specified hctx")
needs to check queue mapping via tag set in hctx's cpuhp handler.

However, q->tag_set may not be setup yet when the cpuhp handler is
enabled, then kernel oops is triggered.

Fix the issue by setup queue tag_set before initializing hctx.


Affected upstream versions: 6.10
Fixed upstream versions: 0, 6.11.5, 6.12
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 73d964ce4bc8b4de88a7c2e40df494f0d5cd8950
CVE-2024-50093: kernel: thermal: intel: int340x: processor: Fix warning during module unload
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-05T00:00:00+00:00

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

thermal: intel: int340x: processor: Fix warning during module unload

The processor_thermal driver uses pcim_device_enable() to enable a PCI
device, which means the device will be automatically disabled on driver
detach.  Thus there is no need to call pci_disable_device() again on it.

With recent PCI device resource management improvements, e.g. commit
f748a07a0b64 ("PCI: Remove legacy pcim_release()"), this problem is
exposed and triggers the warining below.

 [  224.010735] proc_thermal_pci 0000:00:04.0: disabling already-disabled device
 [  224.010747] WARNING: CPU: 8 PID: 4442 at drivers/pci/pci.c:2250 pci_disable_device+0xe5/0x100
 ...
 [  224.010844] Call Trace:
 [  224.010845]  <TASK>
 [  224.010847]  ? show_regs+0x6d/0x80
 [  224.010851]  ? __warn+0x8c/0x140
 [  224.010854]  ? pci_disable_device+0xe5/0x100
 [  224.010856]  ? report_bug+0x1c9/0x1e0
 [  224.010859]  ? handle_bug+0x46/0x80
 [  224.010862]  ? exc_invalid_op+0x1d/0x80
 [  224.010863]  ? asm_exc_invalid_op+0x1f/0x30
 [  224.010867]  ? pci_disable_device+0xe5/0x100
 [  224.010869]  ? pci_disable_device+0xe5/0x100
 [  224.010871]  ? kfree+0x21a/0x2b0
 [  224.010873]  pcim_disable_device+0x20/0x30
 [  224.010875]  devm_action_release+0x16/0x20
 [  224.010878]  release_nodes+0x47/0xc0
 [  224.010880]  devres_release_all+0x9f/0xe0
 [  224.010883]  device_unbind_cleanup+0x12/0x80
 [  224.010885]  device_release_driver_internal+0x1ca/0x210
 [  224.010887]  driver_detach+0x4e/0xa0
 [  224.010889]  bus_remove_driver+0x6f/0xf0
 [  224.010890]  driver_unregister+0x35/0x60
 [  224.010892]  pci_unregister_driver+0x44/0x90
 [  224.010894]  proc_thermal_pci_driver_exit+0x14/0x5f0 [processor_thermal_device_pci]
 ...
 [  224.010921] ---[ end trace 0000000000000000 ]---

Remove the excess pci_disable_device() calls.

[ rjw: Subject and changelog edits ]


Affected upstream versions: 5.14
Fixed upstream versions: 0, 5.15.168, 6.1.113, 6.11.4, 6.12, 6.6.57
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 8403021b6f32d68a7e3a6b8428ecaf5c153a9974
CVE-2024-50101: kernel: iommu/vt-d: Fix incorrect pci_for_each_dma_alias() for non-PCI devices
Component: kernel
Severity: Low
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-05T00:00:00+00:00

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

iommu/vt-d: Fix incorrect pci_for_each_dma_alias() for non-PCI devices

Previously, the domain_context_clear() function incorrectly called
pci_for_each_dma_alias() to set up context entries for non-PCI devices.
This could lead to kernel hangs or other unexpected behavior.

Add a check to only call pci_for_each_dma_alias() for PCI devices. For
non-PCI devices, domain_context_clear_one() is called directly.


Affected upstream versions: 5.15.142 < 5.15.169, 6.1.66 < 6.1.114, 6.6.5 < 6.6.58, 6.7
Fixed upstream versions: 0, 5.15.169, 6.1.114, 6.11.5, 6.12, 6.6.58
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 0bd9a30c22afb5da203386b811ec31429d2caa78
CVE-2024-50102: kernel: x86: fix user address masking non-canonical speculation issue
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-11-05T00:00:00+00:00

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

x86: fix user address masking non-canonical speculation issue

It turns out that AMD has a "Meltdown Lite(tm)" issue with non-canonical
accesses in kernel space.  And so using just the high bit to decide
whether an access is in user space or kernel space ends up with the good
old "leak speculative data" if you have the right gadget using the
result:

  CVE-2020-12965 “Transient Execution of Non-Canonical Accesses“

Now, the kernel surrounds the access with a STAC/CLAC pair, and those
instructions end up serializing execution on older Zen architectures,
which closes the speculation window.

But that was true only up until Zen 5, which renames the AC bit [1].
That improves performance of STAC/CLAC a lot, but also means that the
speculation window is now open.

Note that this affects not just the new address masking, but also the
regular valid_user_address() check used by access_ok(), and the asm
version of the sign bit check in the get_user() helpers.

It does not affect put_user() or clear_user() variants, since there's no
speculative result to be used in a gadget for those operations.


Affected upstream versions: 6.4
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: 291313693677a345d4f50aae3c68e28b469f601e
CVE-2024-50106: kernel: nfsd: fix race between laundromat and free_stateid
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

A vulnerability was found in the Linux kernel. This issue occurs due to a race condition between the laundromat thread handling revoking delegations and the `free_stateid` operation, leading to a use-after-free issue. The error occurs when a freed stateid is accessed by another operation, which can cause memory corruption.

Statement: This vulnerability is classified as moderate severity. While this issue can lead to a use-after-free condition, its impact is limited to a specific race between two operations: the laundromat thread and `free_stateid`. The issue requires precise timing between these operations to be triggered, which reduces the likelihood of exploitation under normal conditions. Additionally, the vulnerability does not directly expose the system to remote code execution or privilege escalation but instead risks memory corruption or unexpected behavior in NFS delegation handling.

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: 967faa26f313a62e7bebc55d5b8122eaee43b929