huzaifas-sidhpurwala/security-commit huggingface dataset:
CVE-2024-36883: kernel: net: fix out-of-bounds access in ops_init
Component: kernel
Severity: Moderate
CWE: CWE-787 (Out-of-bounds Write)
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-05-30T00:00:00+00:00

An out-of-bounds memory access flaw was found in the Linux kernel’s networking subsystem in how a local user triggers a complex race condition. This flaw allows a local user to crash or potentially escalate their privileges on the system.


Affected upstream versions: 3.0.19 < 3.1, 3.2.3 < 3.3, 3.3
Fixed upstream versions: 0, 3.1, 3.3, 4.19.314, 5.10.217, 5.15.159, 5.4.276, 6.1.91, 6.6.31, 6.8.10, 6.9
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 3cdc34d76c4f777579e28ad373979d36c030cfd3
CVE-2024-36886: kernel: TIPC message reassembly use-after-free remote code execution vulnerability
Component: kernel
Severity: Important
CWE: CWE-416 (Use After Free)
CVSS v3: 7.1 (CVSS:3.1/AV:A/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2024-06-06T00:00:00+00:00

A use-after-free (UAF) flaw exists in the Linux Kernel within the reassembly of fragmented TIPC messages, specifically in the tipc_buf_append() function. The issue results due to a lack of checks in the error handling cleanup and can trigger a UAF on "struct sk_buff", which may lead to remote code execution.

Statement: While the TIPC module is not loaded by default, this flaw might be used as one in a series of attacks. For that reason, and because of the possibility of remote code execution on systems where this module has been loaded, Red Hat assesses the impact of this flaw as Important.

Affected upstream versions: 4.1
Fixed upstream versions: 0, 4.19.314, 5.10.217, 5.15.159, 5.4.276, 6.1.91, 6.6.31, 6.8.10, 6.9
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: e19ec8ab0e25bc4803d7cc91c84e84532e2781bd
CVE-2024-36889: kernel: mptcp: ensure snd_nxt is properly initialized on connect
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-05-30T00:00:00+00:00

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

mptcp: ensure snd_nxt is properly initialized on connect

Christoph reported a splat hinting at a corrupted snd_una:

  WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005
  Modules linked in:
  CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 #59
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
  Workqueue: events mptcp_worker
  RIP: 0010:__mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005
  Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8
  	8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe
  	<0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9
  RSP: 0018:ffffc9000013fd48 EFLAGS: 00010293
  RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4
  RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001
  RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
  R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000
  R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000
  FS:  0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0
  Call Trace:
   <TASK>
   __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline]
   mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline]
   __mptcp_retrans+0x7f/0x7e0 net/mptcp/protocol.c:2615
   mptcp_worker+0x434/0x740 net/mptcp/protocol.c:2767
   process_one_work+0x1e0/0x560 kernel/workqueue.c:3254
   process_scheduled_works kernel/workqueue.c:3335 [inline]
   worker_thread+0x3c7/0x640 kernel/workqueue.c:3416
   kthread+0x121/0x170 kernel/kthread.c:388
   ret_from_fork+0x44/0x50 arch/x86/kernel/process.c:147
   ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243
   </TASK>

When fallback to TCP happens early on a client socket, snd_nxt
is not yet initialized and any incoming ack will copy such value
into snd_una. If the mptcp worker (dumbly) tries mptcp-level
re-injection after such ack, that would unconditionally trigger a send
buffer cleanup using 'bad' snd_una values.

We could easily disable re-injection for fallback sockets, but such
dumb behavior already helped catching a few subtle issues and a very
low to zero impact in practice.

Instead address the issue always initializing snd_nxt (and write_seq,
for consistency) at connect time.


Affected upstream versions: 5.9
Fixed upstream versions: 0, 5.10.218, 5.15.159, 6.1.91, 6.6.31, 6.8.10, 6.9
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 99951b62bf20cec9247f633a3bea898338b9e5b4
CVE-2024-36891: kernel: maple_tree: fix mas_empty_area_rev() null pointer dereference
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-05-30T00:00:00+00:00

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

maple_tree: fix mas_empty_area_rev() null pointer dereference

Currently the code calls mas_start() followed by mas_data_end() if the
maple state is MA_START, but mas_start() may return with the maple state
node == NULL.  This will lead to a null pointer dereference when checking
information in the NULL node, which is done in mas_data_end().

Avoid setting the offset if there is no node by waiting until after the
maple state is checked for an empty or single entry state.

A user could trigger the events to cause a kernel oops by unmapping all
vmas to produce an empty maple tree, then mapping a vma that would cause
the scenario described above.


Affected upstream versions: 6.1
Fixed upstream versions: 0, 6.1.94, 6.6.31, 6.8.10, 6.9
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 883e5d542bbdddbddeba60250cb482baf3ae2415
CVE-2024-36896: kernel: USB: core: Fix access violation during port device removal
Component: kernel
Severity: Low
CWE: CWE-170 (Improper Null Termination)
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-05-30T00:00:00+00:00

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

USB: core: Fix access violation during port device removal

Testing with KASAN and syzkaller revealed a bug in port.c:disable_store():
usb_hub_to_struct_hub() can return NULL if the hub that the port belongs to
is concurrently removed, but the function does not check for this
possibility before dereferencing the returned value.

It turns out that the first dereference is unnecessary, since hub->intfdev
is the parent of the port device, so it can be changed easily.  Adding a
check for hub == NULL prevents further problems.

The same bug exists in the disable_show() routine, and it can be fixed the
same way.


Affected upstream versions: 6.0
Fixed upstream versions: 0, 6.1.91, 6.6.31, 6.8.10, 6.9
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 5f1d68ef5ddac27c6b997adccd1c339cef1e6848
CVE-2024-36899: kernel: gpiolib: cdev: Fix use after free in lineinfo_changed_notify
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-05-30T00:00:00+00:00

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

gpiolib: cdev: Fix use after free in lineinfo_changed_notify

The use-after-free issue occurs as follows: when the GPIO chip device file
is being closed by invoking gpio_chrdev_release(), watched_lines is freed
by bitmap_free(), but the unregistration of lineinfo_changed_nb notifier
chain failed due to waiting write rwsem. Additionally, one of the GPIO
chip's lines is also in the release process and holds the notifier chain's
read rwsem. Consequently, a race condition leads to the use-after-free of
watched_lines.

Here is the typical stack when issue happened:

[free]
gpio_chrdev_release()
  --> bitmap_free(cdev->watched_lines)                  <-- freed
  --> blocking_notifier_chain_unregister()
    --> down_write(&nh->rwsem)                          <-- waiting rwsem
          --> __down_write_common()
            --> rwsem_down_write_slowpath()
                  --> schedule_preempt_disabled()
                    --> schedule()

[use]
st54spi_gpio_dev_release()
  --> gpio_free()
    --> gpiod_free()
      --> gpiod_free_commit()
        --> gpiod_line_state_notify()
          --> blocking_notifier_call_chain()
            --> down_read(&nh->rwsem);                  <-- held rwsem
            --> notifier_call_chain()
              --> lineinfo_changed_notify()
                --> test_bit(xxxx, cdev->watched_lines) <-- use after free

The side effect of the use-after-free issue is that a GPIO line event is
being generated for userspace where it shouldn't. However, since the chrdev
is being closed, userspace won't have the chance to read that event anyway.

To fix the issue, call the bitmap_free() function after the unregistration
of lineinfo_changed_nb notifier chain.


Affected upstream versions: 5.7
Fixed upstream versions: 0, 5.10.234, 5.15.177, 6.1.127, 6.6.31, 6.8.10, 6.9
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 2dfbb920a89bdc58087672ad5325dc6c588b6860
CVE-2024-36903: kernel: ipv6: Fix potential uninit-value access in __ip6_make_skb()
Component: kernel
Severity: Moderate
CWE: CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'))
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-05-30T00:00:00+00:00

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

ipv6: Fix potential uninit-value access in __ip6_make_skb()

As it was done in commit fc1092f51567 ("ipv4: Fix uninit-value access in
__ip_make_skb()") for IPv4, check FLOWI_FLAG_KNOWN_NH on fl6->flowi6_flags
instead of testing HDRINCL on the socket to avoid a race condition which
causes uninit-value access.


Affected upstream versions: 5.10.178 < 5.10.248, 5.15.107 < 5.15.198, 6.1.24 < 6.1.140, 4.14.313 < 4.15, 4.19.281 < 4.20, 5.4.241 < 5.5, 6.2.11 < 6.3, 6.3
Fixed upstream versions: 0, 4.15, 4.20, 5.10.248, 5.15.198, 5.5, 6.1.140, 6.3, 6.6.31, 6.8.10, 6.9
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 59d74c843ebf46264c7903726cf6f2673a93b07a
CVE-2024-36904: kernel: tcp: Use refcount_inc_not_zero() in tcp_twsk_unique().
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-05-30T00:00:00+00:00

A use-after-free flaw was found in the Linux kernel’s TCP protocol in how a local user triggers a complex race condition during connection to the socket. This flaw allows a local user to crash or potentially escalate their privileges on the system.


Affected upstream versions: 4.16
Fixed upstream versions: 0, 4.19.314, 5.10.217, 5.15.159, 5.4.276, 6.1.91, 6.6.31, 6.8.10, 6.9
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 84546cc1aeeb4df3e444b18a4293c9823f974be9
CVE-2024-36917: kernel: block: fix overflow in blk_ioctl_discard()
Component: kernel
Severity: Low
CWE: CWE-190 (Integer Overflow or Wraparound)
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-05-30T00:00:00+00:00

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

block: fix overflow in blk_ioctl_discard()

There is no check for overflow of 'start + len' in blk_ioctl_discard().
Hung task occurs if submit an discard ioctl with the following param:
  start = 0x80000000000ff000, len = 0x8000000000fff000;
Add the overflow validation now.


Affected upstream versions: 2.6.28
Fixed upstream versions: 0, 6.1.91, 6.6.31, 6.8.10, 6.9
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 8a26198186e97ee5fc4b42fde82629cff8c75cd6
CVE-2024-36920: kernel: scsi: mpi3mr: Avoid memcpy field-spanning write WARNING
Component: kernel
Severity: Low
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-05-30T00:00:00+00:00

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

scsi: mpi3mr: Avoid memcpy field-spanning write WARNING

When the "storcli2 show" command is executed for eHBA-9600, mpi3mr driver
prints this WARNING message:

  memcpy: detected field-spanning write (size 128) of single field "bsg_reply_buf->reply_buf" at drivers/scsi/mpi3mr/mpi3mr_app.c:1658 (size 1)
  WARNING: CPU: 0 PID: 12760 at drivers/scsi/mpi3mr/mpi3mr_app.c:1658 mpi3mr_bsg_request+0x6b12/0x7f10 [mpi3mr]

The cause of the WARN is 128 bytes memcpy to the 1 byte size array "__u8
replay_buf[1]" in the struct mpi3mr_bsg_in_reply_buf. The array is intended
to be a flexible length array, so the WARN is a false positive.

To suppress the WARN, remove the constant number '1' from the array
declaration and clarify that it has flexible length. Also, adjust the
memory allocation size to match the change.


Affected upstream versions: 5.14
Fixed upstream versions: 0, 6.1.91, 6.6.31, 6.8.10, 6.9
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 5f0266044dc611563539705bff0b3e1545fbb6aa
CVE-2024-36921: kernel: wifi: iwlwifi: mvm: guard against invalid STA ID on removal
Component: kernel
Severity: Moderate
CWE: CWE-125 (Out-of-bounds Read)
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-05-30T00:00:00+00:00

An out-of-bounds memory access flaw was found in the Linux kernel’s Wireless WiFi Link Next-Gen AGN driver in how a user removes it. This flaw allows a local user to crash or potentially escalate their privileges on the system.


Affected upstream versions: 6.4
Fixed upstream versions: 0, 6.6.31, 6.8.10, 6.9
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 94f80a8ec15e238b78521f20f8afaed60521a294
CVE-2024-36922: kernel: wifi: iwlwifi: read txq-&gt;read_ptr under lock
Component: kernel
Severity: Low
CWE: CWE-413 (Improper Resource Locking)
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-05-30T00:00:00+00:00

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

wifi: iwlwifi: read txq->read_ptr under lock

If we read txq->read_ptr without lock, we can read the same
value twice, then obtain the lock, and reclaim from there
to two different places, but crucially reclaim the same
entry twice, resulting in the WARN_ONCE() a little later.
Fix that by reading txq->read_ptr under lock.


Affected upstream versions: 4.19
Fixed upstream versions: 0, 5.15.209, 6.1.175, 6.6.31, 6.8.10, 6.9
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: f30e8af109818c9db08cbcc46eb9713fe4b530ba
CVE-2024-36924: kernel: scsi: lpfc: Release hbalock before calling lpfc_worker_wake_up()
Component: kernel
Severity: Moderate
CWE: CWE-833 (Deadlock)
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-05-30T00:00:00+00:00

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

scsi: lpfc: Release hbalock before calling lpfc_worker_wake_up()

lpfc_worker_wake_up() calls the lpfc_work_done() routine, which takes the
hbalock.  Thus, lpfc_worker_wake_up() should not be called while holding the
hbalock to avoid potential deadlock.


Affected upstream versions: 2.6.23
Fixed upstream versions: 0, 6.1.91, 6.6.31, 6.8.10, 6.9
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 6503c39398506cadda9f4c81695a9655ca5fb4fd
CVE-2024-36926: kernel: powerpc/pseries/iommu: LPAR panics during boot up with a frozen PE
Component: kernel
Severity: Low
CWE: CWE-476 (NULL Pointer Dereference)
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-05-30T00:00:00+00:00

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

powerpc/pseries/iommu: LPAR panics during boot up with a frozen PE

At the time of LPAR boot up, partition firmware provides Open Firmware
property ibm,dma-window for the PE. This property is provided on the PCI
bus the PE is attached to.

There are execptions where the partition firmware might not provide this
property for the PE at the time of LPAR boot up. One of the scenario is
where the firmware has frozen the PE due to some error condition. This
PE is frozen for 24 hours or unless the whole system is reinitialized.

Within this time frame, if the LPAR is booted, the frozen PE will be
presented to the LPAR but ibm,dma-window property could be missing.

Today, under these circumstances, the LPAR oopses with NULL pointer
dereference, when configuring the PCI bus the PE is attached to.

  BUG: Kernel NULL pointer dereference on read at 0x000000c8
  Faulting instruction address: 0xc0000000001024c0
  Oops: Kernel access of bad area, sig: 7 [#1]
  LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
  Modules linked in:
  Supported: Yes
  CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.4.0-150600.9-default #1
  Hardware name: IBM,9043-MRX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NM1060_023) hv:phyp pSeries
  NIP:  c0000000001024c0 LR: c0000000001024b0 CTR: c000000000102450
  REGS: c0000000037db5c0 TRAP: 0300   Not tainted  (6.4.0-150600.9-default)
  MSR:  8000000002009033 <SF,VEC,EE,ME,IR,DR,RI,LE>  CR: 28000822  XER: 00000000
  CFAR: c00000000010254c DAR: 00000000000000c8 DSISR: 00080000 IRQMASK: 0
  ...
  NIP [c0000000001024c0] pci_dma_bus_setup_pSeriesLP+0x70/0x2a0
  LR [c0000000001024b0] pci_dma_bus_setup_pSeriesLP+0x60/0x2a0
  Call Trace:
    pci_dma_bus_setup_pSeriesLP+0x60/0x2a0 (unreliable)
    pcibios_setup_bus_self+0x1c0/0x370
    __of_scan_bus+0x2f8/0x330
    pcibios_scan_phb+0x280/0x3d0
    pcibios_init+0x88/0x12c
    do_one_initcall+0x60/0x320
    kernel_init_freeable+0x344/0x3e4
    kernel_init+0x34/0x1d0
    ret_from_kernel_user_thread+0x14/0x1c


Affected upstream versions: 5.18.18 < 5.19, 5.19.2 < 5.20, 6.0
Fixed upstream versions: 0, 5.19, 5.20, 6.1.91, 6.6.31, 6.8.10, 6.9
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 7fb5793c53f8c024e3eae9f0d44eb659aed833c4
CVE-2024-36929: kernel: net: core: reject skb_copy(_expand) for fraglist GSO skbs
Component: kernel
Severity: Moderate
CWE: CWE-822 (Untrusted 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-05-30T00:00:00+00:00

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

net: core: reject skb_copy(_expand) for fraglist GSO skbs

SKB_GSO_FRAGLIST skbs must not be linearized, otherwise they become
invalid. Return NULL if such an skb is passed to skb_copy or
skb_copy_expand, in order to prevent a crash on a potential later
call to skb_gso_segment.


Affected upstream versions: 5.6
Fixed upstream versions: 0, 5.10.217, 5.15.159, 6.1.91, 6.6.31, 6.8.10, 6.9
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: faa83a7797f06cefed86731ba4baa3b4dfdc06c1
CVE-2024-36930: kernel: spi: fix null pointer dereference within spi_sync
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-05-30T00:00:00+00:00

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

spi: fix null pointer dereference within spi_sync

If spi_sync() is called with the non-empty queue and the same spi_message
is then reused, the complete callback for the message remains set while
the context is cleared, leading to a null pointer dereference when the
callback is invoked from spi_finalize_current_message().

With function inlining disabled, the call stack might look like this:

  _raw_spin_lock_irqsave from complete_with_flags+0x18/0x58
  complete_with_flags from spi_complete+0x8/0xc
  spi_complete from spi_finalize_current_message+0xec/0x184
  spi_finalize_current_message from spi_transfer_one_message+0x2a8/0x474
  spi_transfer_one_message from __spi_pump_transfer_message+0x104/0x230
  __spi_pump_transfer_message from __spi_transfer_message_noqueue+0x30/0xc4
  __spi_transfer_message_noqueue from __spi_sync+0x204/0x248
  __spi_sync from spi_sync+0x24/0x3c
  spi_sync from mcp251xfd_regmap_crc_read+0x124/0x28c [mcp251xfd]
  mcp251xfd_regmap_crc_read [mcp251xfd] from _regmap_raw_read+0xf8/0x154
  _regmap_raw_read from _regmap_bus_read+0x44/0x70
  _regmap_bus_read from _regmap_read+0x60/0xd8
  _regmap_read from regmap_read+0x3c/0x5c
  regmap_read from mcp251xfd_alloc_can_err_skb+0x1c/0x54 [mcp251xfd]
  mcp251xfd_alloc_can_err_skb [mcp251xfd] from mcp251xfd_irq+0x194/0xe70 [mcp251xfd]
  mcp251xfd_irq [mcp251xfd] from irq_thread_fn+0x1c/0x78
  irq_thread_fn from irq_thread+0x118/0x1f4
  irq_thread from kthread+0xd8/0xf4
  kthread from ret_from_fork+0x14/0x28

Fix this by also setting message->complete to NULL when the transfer is
complete.


Affected upstream versions: 6.0
Fixed upstream versions: 0, 6.1.91, 6.6.31, 6.8.10, 6.9
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: e005d6754e3e440257006795b687c4ad8733b493
CVE-2024-36932: kernel: thermal/debugfs: Prevent use-after-free from occurring after cdev removal
Component: kernel
Severity: Low
CWE: CWE-416 (Use After Free)
CVSS v3: 5.1 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:H)
Public date: 2024-05-30T00:00:00+00:00

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

thermal/debugfs: Prevent use-after-free from occurring after cdev removal

Since thermal_debug_cdev_remove() does not run under cdev->lock, it can
run in parallel with thermal_debug_cdev_state_update() and it may free
the struct thermal_debugfs object used by the latter after it has been
checked against NULL.

If that happens, thermal_debug_cdev_state_update() will access memory
that has been freed already causing the kernel to crash.

Address this by using cdev->lock in thermal_debug_cdev_remove() around
the cdev->debugfs value check (in case the same cdev is removed at the
same time in two different threads) and its reset to NULL.

Cc :6.8+ <stable@vger.kernel.org> # 6.8+


Affected upstream versions: 6.8
Fixed upstream versions: 0, 6.8.10, 6.9
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: c1279dee33369e2525f532364bb87207d23b9481