deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2024-35991
Published: 2024-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

dmaengine: idxd: Convert spinlock to mutex to lock evl workqueue

drain_workqueue() cannot be called safely in a spinlocked context due to
possible task rescheduling. In the multi-task scenario, calling
queue_work() while drain_workqueue() will lead to a Call Trace as
pushing a work on a draining workqueue is not permitted in spinlocked
context.
    Call Trace:
    <TASK>
    ? __warn+0x7d/0x140
    ? __queue_work+0x2b2/0x440
    ? report_bug+0x1f8/0x200
    ? handle_bug+0x3c/0x70
    ? exc_invalid_op+0x18/0x70
    ? asm_exc_invalid_op+0x1a/0x20
    ? __queue_work+0x2b2/0x440
    queue_work_on+0x28/0x30
    idxd_misc_thread+0x303/0x5a0 [idxd]
    ? __schedule+0x369/0xb40
    ? __pfx_irq_thread_fn+0x10/0x10
    ? irq_thread+0xbc/0x1b0
    irq_thread_fn+0x21/0x70
    irq_thread+0x102/0x1b0
    ? preempt_count_add+0x74/0xa0
    ? __pfx_irq_thread_dtor+0x10/0x10
    ? __pfx_irq_thread+0x10/0x10
    kthread+0x103/0x140
    ? __pfx_kthread+0x10/0x10
    ret_from_fork+0x31/0x50
    ? __pfx_kthread+0x10/0x10
    ret_from_fork_asm+0x1b/0x30
    </TASK>

The current implementation uses a spinlock to protect event log workqueue
and will lead to the Call Trace due to potential task rescheduling.

To address the locking issue, convert the spinlock to mutex, allowing
the drain_workqueue() to be called in a safe mutex-locked context.

This change ensures proper synchronization when accessing the event log
workqueue, preventing potential Call Trace and improving the overall
robustness of the code.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/758071a35d9f3ffd84ff12169d081412a2f5f098; https://git.kernel.org/stable/c/c9b732a9f73eadc638abdcf0a6d39bc7a0c1af5f; https://git.kernel.org/stable/c/d5638de827cff0fce77007e426ec0ffdedf68a44
CVE: CVE-2024-35992
Published: 2024-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

phy: marvell: a3700-comphy: Fix out of bounds read

There is an out of bounds read access of 'gbe_phy_init_fix[fix_idx].addr'
every iteration after 'fix_idx' reaches 'ARRAY_SIZE(gbe_phy_init_fix)'.

Make sure 'gbe_phy_init[addr]' is used when all elements of
'gbe_phy_init_fix' array are handled.

Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-125
References: https://git.kernel.org/stable/c/40406dfbc060503d2e0a9e637e98493c54997b3d; https://git.kernel.org/stable/c/610f175d2e16fb2436ba7974b990563002c20d07; https://git.kernel.org/stable/c/976df695f579bbb2914114b4e9974fe4ed1eb813
CVE: CVE-2024-35993
Published: 2024-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

mm: turn folio_test_hugetlb into a PageType

The current folio_test_hugetlb() can be fooled by a concurrent folio split
into returning true for a folio which has never belonged to hugetlbfs. 
This can't happen if the caller holds a refcount on it, but we have a few
places (memory-failure, compaction, procfs) which do not and should not
take a speculative reference.

Since hugetlb pages do not use individual page mapcounts (they are always
fully mapped and use the entire_mapcount field to record the number of
mappings), the PageType field is available now that page_mapcount()
ignores the value in this field.

In compaction and with CONFIG_DEBUG_VM enabled, the current implementation
can result in an oops, as reported by Luis. This happens since 9c5ccf2db04b
("mm: remove HUGETLB_PAGE_DTOR") effectively added some VM_BUG_ON() checks
in the PageHuge() testing path.

[willy@infradead.org: update vmcoreinfo]
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2431b5f2650dfc47ce782d1ca7b02d6b3916976f; https://git.kernel.org/stable/c/9fdcc5b6359dfdaa52a55033bf50e2cedd66eb32; https://git.kernel.org/stable/c/d99e3140a4d33e26066183ff727d8f02f56bec64
CVE: CVE-2024-35994
Published: 2024-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

firmware: qcom: uefisecapp: Fix memory related IO errors and crashes

It turns out that while the QSEECOM APP_SEND command has specific fields
for request and response buffers, uefisecapp expects them both to be in
a single memory region. Failure to adhere to this has (so far) resulted
in either no response being written to the response buffer (causing an
EIO to be emitted down the line), the SCM call to fail with EINVAL
(i.e., directly from TZ/firmware), or the device to be hard-reset.

While this issue can be triggered deterministically, in the current form
it seems to happen rather sporadically (which is why it has gone
unnoticed during earlier testing). This is likely due to the two
kzalloc() calls (for request and response) being directly after each
other. Which means that those likely return consecutive regions most of
the time, especially when not much else is going on in the system.

Fix this by allocating a single memory region for both request and
response buffers, properly aligning both structs inside it. This
unfortunately also means that the qcom_scm_qseecom_app_send() interface
needs to be restructured, as it should no longer map the DMA regions
separately. Therefore, move the responsibility of DMA allocation (or
mapping) to the caller.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/dd22b34fb53cb04b13b2f5eee5c9200bb091fc88; https://git.kernel.org/stable/c/ed09f81eeaa8f9265e1787282cb283f10285c259; https://git.kernel.org/stable/c/dd22b34fb53cb04b13b2f5eee5c9200bb091fc88
CVE: CVE-2024-35995
Published: 2024-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

ACPI: CPPC: Use access_width over bit_width for system memory accesses

To align with ACPI 6.3+, since bit_width can be any 8-bit value, it
cannot be depended on to be always on a clean 8b boundary. This was
uncovered on the Cobalt 100 platform.

SError Interrupt on CPU26, code 0xbe000011 -- SError
 CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1
 Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION
 pstate: 62400009 (nZCv daif +PAN -UAO +TCO -DIT -SSBS BTYPE=--)
 pc : cppc_get_perf_caps+0xec/0x410
 lr : cppc_get_perf_caps+0xe8/0x410
 sp : ffff8000155ab730
 x29: ffff8000155ab730 x28: ffff0080139d0038 x27: ffff0080139d0078
 x26: [PII_REDACTED] x25: ffff0080139d0058 x24: 00000000ffffffff
 x23: ffff0080139d0298 x22: ffff0080139d0278 x21: [PII_REDACTED]
 x20: ffff00802b251910 x19: ffff0080139d0000 x18: ffffffffffffffff
 x17: [PII_REDACTED] x16: ffffdc7e111bad04 x15: ffff00802b251008
 x14: ffffffffffffffff x13: ffff013f1fd63300 x12: [PII_REDACTED]
 x11: ffffdc7e128f4420 x10: [PII_REDACTED] x9 : ffffdc7e111badec
 x8 : ffff00802b251980 x7 : [PII_REDACTED] x6 : ffff0080139d0028
 x5 : [PII_REDACTED] x4 : ffff0080139d0018 x3 : 00000000ffffffff
 x2 : [PII_REDACTED] x1 : ffff8000155ab7a0 x0 : [PII_REDACTED]
 Kernel panic - not syncing: Asynchronous SError Interrupt
 CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted
5.15.2.1-13 #1
 Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION
 Call trace:
  dump_backtrace+0x0/0x1e0
  show_stack+0x24/0x30
  dump_stack_lvl+0x8c/0xb8
  dump_stack+0x18/0x34
  panic+0x16c/0x384
  add_taint+0x0/0xc0
  arm64_serror_panic+0x7c/0x90
  arm64_is_fatal_ras_serror+0x34/0xa4
  do_serror+0x50/0x6c
  el1h_64_error_handler+0x40/0x74
  el1h_64_error+0x7c/0x80
  cppc_get_perf_caps+0xec/0x410
  cppc_cpufreq_cpu_init+0x74/0x400 [cppc_cpufreq]
  cpufreq_online+0x2dc/0xa30
  cpufreq_add_dev+0xc0/0xd4
  subsys_interface_register+0x134/0x14c
  cpufreq_register_driver+0x1b0/0x354
  cppc_cpufreq_init+0x1a8/0x1000 [cppc_cpufreq]
  do_one_initcall+0x50/0x250
  do_init_module+0x60/0x27c
  load_module+0x2300/0x2570
  __do_sys_finit_module+0xa8/0x114
  __arm64_sys_finit_module+0x2c/0x3c
  invoke_syscall+0x78/0x100
  el0_svc_common.constprop.0+0x180/0x1a0
  do_el0_svc+0x84/0xa0
  el0_svc+0x2c/0xc0
  el0t_64_sync_handler+0xa4/0x12c
  el0t_64_sync+0x1a4/0x1a8

Instead, use access_width to determine the size and use the offset and
width to shift and mask the bits to read/write out. Make sure to add a
check for system memory since pcc redefines the access_width to
subspace id.

If access_width is not set, then fall back to using bit_width.

[ rjw: Subject and changelog edits, comment adjustments ]
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/01fc53be672acae37e611c80cc0b4f3939584de3; https://git.kernel.org/stable/c/1b890ae474d19800a6be1696df7fb4d9a41676e4; https://git.kernel.org/stable/c/2f4a4d63a193be6fd530d180bb13c[PII_REDACTED]c
CVE: CVE-2024-35996
Published: 2024-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

cpu: Re-enable CPU mitigations by default for !X86 architectures

Rename x86's to CPU_MITIGATIONS, define it in generic code, and force it
on for all architectures exception x86.  A recent commit to turn
mitigations off by default if SPECULATION_MITIGATIONS=n kinda sorta
missed that "cpu_mitigations" is completely generic, whereas
SPECULATION_MITIGATIONS is x86-specific.

Rename x86's SPECULATIVE_MITIGATIONS instead of keeping both and have it
select CPU_MITIGATIONS, as having two configs for the same thing is
unnecessary and confusing.  This will also allow x86 to use the knob to
manage mitigations that aren't strictly related to speculative
execution.

Use another Kconfig to communicate to common code that CPU_MITIGATIONS
is already defined instead of having x86's menu depend on the common
CPU_MITIGATIONS.  This allows keeping a single point of contact for all
of x86's mitigations, and it's not clear that other architectures *want*
to allow disabling mitigations at compile-time.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/36b32816fbab267611f073223f1b0b816ec5920f; https://git.kernel.org/stable/c/38f17d1fbb5bfb56ca1419e2d06376d57a9396f9; https://git.kernel.org/stable/c/8292f4f8dd1b005d0688d726261004f816ef730a
CVE: CVE-2024-35997
Published: 2024-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

HID: i2c-hid: remove I2C_HID_READ_PENDING flag to prevent lock-up

The flag I2C_HID_READ_PENDING is used to serialize I2C operations.
However, this is not necessary, because I2C core already has its own
locking for that.

More importantly, this flag can cause a lock-up: if the flag is set in
i2c_hid_xfer() and an interrupt happens, the interrupt handler
(i2c_hid_irq) will check this flag and return immediately without doing
anything, then the interrupt handler will be invoked again in an
infinite loop.

Since interrupt handler is an RT task, it takes over the CPU and the
flag-clearing task never gets scheduled, thus we have a lock-up.

Delete this unnecessary flag.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/0561b65fbd53d3e788c5b0222d9112ca016fd6a1; https://git.kernel.org/stable/c/21bfca822cfc1e71796124e93b46e0d9fa584401; https://git.kernel.org/stable/c/29e94f295bad5be59cf4271a93e22cdcf5536722
CVE: CVE-2024-35998
Published: 2024-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

smb3: fix lock ordering potential deadlock in cifs_sync_mid_result

Coverity spotted that the cifs_sync_mid_result function could deadlock

"Thread deadlock (ORDER_REVERSAL) lock_order: Calling spin_lock acquires
lock TCP_Server_Info.srv_lock while holding lock TCP_Server_Info.mid_lock"

Addresses-Coverity: 1590401 ("Thread deadlock (ORDER_REVERSAL)")
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/699f8958dece132709c0bff6a9700999a2a63b75; https://git.kernel.org/stable/c/8248224ab5b8ca7559b671917c224296a4d671fc; https://git.kernel.org/stable/c/8861fd5180476f45f9e8853db154600469a0284f
CVE: CVE-2024-35999
Published: 2024-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

smb3: missing lock when picking channel

Coverity spotted a place where we should have been holding the
channel lock when accessing the ses channel index.

Addresses-Coverity: 1582039 ("Data race condition (MISSING_LOCK)")
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/0fcf7e219448e[PII_REDACTED]53c9a58abae6d3c2e; https://git.kernel.org/stable/c/60ab[PII_REDACTED]05603bc0d3654f4cf8fceccb00; https://git.kernel.org/stable/c/8094a600245e9b28eb36a13036f202ad67c1f887
CVE: CVE-2024-36000
Published: 2024-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

mm/hugetlb: fix missing hugetlb_lock for resv uncharge

There is a recent report on UFFDIO_COPY over hugetlb:

https://lore.kernel.org/all/[PII_REDACTED]00ee06de[PII_REDACTED]@google.com/

350:	lockdep_assert_held(&hugetlb_lock);

Should be an issue in hugetlb but triggered in an userfault context, where
it goes into the unlikely path where two threads modifying the resv map
together.  Mike has a fix in that path for resv uncharge but it looks like
the locking criteria was overlooked: hugetlb_cgroup_uncharge_folio_rsvd()
will update the cgroup pointer, so it requires to be called with the lock
held.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-617
References: https://git.kernel.org/stable/c/4c806333efea1000a2a9620926f560ad2e1ca7cc; https://git.kernel.org/stable/c/538faabf31e9c53d8c870d114846fda958a0de10; https://git.kernel.org/stable/c/b76b46902c2d0395488c8412e1116c2486cdfcb2
CVE: CVE-2024-36001
Published: 2024-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

netfs: Fix the pre-flush when appending to a file in writethrough mode

In netfs_perform_write(), when the file is marked NETFS_ICTX_WRITETHROUGH
or O_*SYNC or RWF_*SYNC was specified, write-through caching is performed
on a buffered file.  When setting up for write-through, we flush any
conflicting writes in the region and wait for the write to complete,
failing if there's a write error to return.

The issue arises if we're writing at or above the EOF position because we
skip the flush and - more importantly - the wait.  This becomes a problem
if there's a partial folio at the end of the file that is being written out
and we want to make a write to it too.  Both the already-running write and
the write we start both want to clear the writeback mark, but whoever is
second causes a warning looking something like:

    ------------[ cut here ]------------
    R=00000012: folio 11 is not under writeback
    WARNING: CPU: 34 PID: 654 at fs/netfs/write_collect.c:105
    ...
    CPU: 34 PID: 654 Comm: kworker/u386:27 Tainted: G S ...
    ...
    Workqueue: events_unbound netfs_write_collection_worker
    ...
    RIP: 0010:netfs_writeback_lookup_folio

Fix this by making the flush-and-wait unconditional.  It will do nothing if
there are no folios in the pagecache and will return quickly if there are
no folios in the region specified.

Further, move the WBC attachment above the flush call as the flush is going
to attach a WBC and detach it again if it is not present - and since we
need one anyway we might as well share it.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/5eaf23b2e81349f6614f88396dc468fda89fc0b9; https://git.kernel.org/stable/c/c97f59e276d4e93480f29a70accbd0d7273cf3f5; https://git.kernel.org/stable/c/5eaf23b2e81349f6614f88396dc468fda89fc0b9
CVE: CVE-2024-36002
Published: 2024-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

dpll: fix dpll_pin_on_pin_register() for multiple parent pins

In scenario where pin is registered with multiple parent pins via
dpll_pin_on_pin_register(..), all belonging to the same dpll device.
A second call to dpll_pin_on_pin_unregister(..) would cause a call trace,
as it tries to use already released registration resources (due to fix
introduced in b446631f355e). In this scenario pin was registered twice,
so resources are not yet expected to be release until each registered
pin/pin pair is unregistered.

Currently, the following crash/call trace is produced when ice driver is
removed on the system with installed E810T NIC which includes dpll device:

WARNING: CPU: 51 PID: 9155 at drivers/dpll/dpll_core.c:809 dpll_pin_ops+0x20/0x30
RIP: 0010:dpll_pin_ops+0x20/0x30
Call Trace:
 ? __warn+0x7f/0x130
 ? dpll_pin_ops+0x20/0x30
 dpll_msg_add_pin_freq+0x37/0x1d0
 dpll_cmd_pin_get_one+0x1c0/0x400
 ? __nlmsg_put+0x63/0x80
 dpll_pin_event_send+0x93/0x140
 dpll_pin_on_pin_unregister+0x3f/0x100
 ice_dpll_deinit_pins+0xa1/0x230 [ice]
 ice_remove+0xf1/0x210 [ice]

Fix by adding a parent pointer as a cookie when creating a registration,
also when searching for it. For the regular pins pass NULL, this allows to
create separated registration for each parent the pin is registered with.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/38d7b94e81d068b8d8c8392f421cfd2c3bbfd1a6; https://git.kernel.org/stable/c/f3e1cf62d18220a3aa97e084e7a3552debece9fc; https://git.kernel.org/stable/c/38d7b94e81d068b8d8c8392f421cfd2c3bbfd1a6
CVE: CVE-2024-36005
Published: 2024-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

netfilter: nf_tables: honor table dormant flag from netdev release event path

Check for table dormant flag otherwise netdev release event path tries
to unregister an already unregistered hook.

[[PII_REDACTED]99] ------------[ cut here ]------------
[[PII_REDACTED]10] WARNING: CPU: 0 PID: 3386599 at net/netfilter/core.c:501 __nf_unregister_net_hook+0x21a/0x260
[...]
[[PII_REDACTED]48] CPU: 0 PID: 3386599 Comm: kworker/u32:2 Not tainted 6.9.0-rc3+ #365
[[PII_REDACTED]69] Workqueue: netns cleanup_net
[[PII_REDACTED]86] RIP: 0010:__nf_unregister_net_hook+0x21a/0x260
[[PII_REDACTED]03] Code: 24 e8 aa 73 83 ff 48 63 43 1c 83 f8 01 0f 85 3d ff ff ff e8 98 d1 f0 ff 48 8b 3c 24 e8 8f 73 83 ff 48 63 43 1c e9 26 ff ff ff <0f> 0b 48 83 c4 18 48 c7 c7 00 68 e9 82 5b 5d 41 5c 41 5d 41 5e 41
[[PII_REDACTED]14] RSP: 0018:ffff8881e36d79e0 EFLAGS: 00010246
[[PII_REDACTED]26] RAX: [PII_REDACTED] RBX: ffff8881339ae790 RCX: ffffffff81ba524a
[[PII_REDACTED]36] RDX: dffffc[PII_REDACTED] RSI: [PII_REDACTED] RDI: ffff8881c8a16438
[[PII_REDACTED]45] RBP: ffff8881c8a16438 R08: [PII_REDACTED] R09: ffffed103c6daf34
[[PII_REDACTED]54] R10: ffff8881e36d79a7 R11: [PII_REDACTED] R12: [PII_REDACTED]
[[PII_REDACTED]62] R13: ffff8881c8a16000 R14: [PII_REDACTED] R15: ffff8881351b5a00
[[PII_REDACTED]71] FS:  [PII_REDACTED](0000) GS:ffff[PII_REDACTED]00(0000) knlGS:[PII_REDACTED]
[[PII_REDACTED]82] CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
[[PII_REDACTED]91] CR2: 00007fc9be0f16f4 CR3:[PII_REDACTED]7cc004 CR4:[PII_REDACTED]1706f0
[[PII_REDACTED]00] Call Trace:
[[PII_REDACTED]06]  <TASK>
[[PII_REDACTED]13]  ? __warn+0x9f/0x1a0
[[PII_REDACTED]27]  ? __nf_unregister_net_hook+0x21a/0x260
[[PII_REDACTED]44]  ? report_bug+0x1b1/0x1e0
[[PII_REDACTED]60]  ? handle_bug+0x3c/0x70
[[PII_REDACTED]71]  ? exc_invalid_op+0x17/0x40
[[PII_REDACTED]83]  ? asm_exc_invalid_op+0x1a/0x20
[[PII_REDACTED]00]  ? __nf_unregister_net_hook+0x6a/0x260
[[PII_REDACTED]16]  ? __nf_unregister_net_hook+0x21a/0x260
[[PII_REDACTED]35]  nf_tables_netdev_event+0x337/0x390 [nf_tables]
[[PII_REDACTED]04]  ? __pfx_nf_tables_netdev_event+0x10/0x10 [nf_tables]
[[PII_REDACTED]61]  ? packet_notifier+0xb3/0x360
[[PII_REDACTED]76]  ? _raw_spin_unlock_irqrestore+0x11/0x40
[[PII_REDACTED]89]  ? dcbnl_netdevice_event+0x35/0x140
[[PII_REDACTED]07]  ? __pfx_nf_tables_netdev_event+0x10/0x10 [nf_tables]
[[PII_REDACTED]61]  notifier_call_chain+0x7d/0x140
[[PII_REDACTED]77]  unregister_netdevice_many_notify+0x5e1/0xae0
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/13ba94f6cc820fdea15efeaa17d4c722874eebf9; https://git.kernel.org/stable/c/5c45feb3c288cf44a529e2657b36c259d86497d2; https://git.kernel.org/stable/c/8260c980aee7d8d8a3db39faf19c391d2f898816
CVE: CVE-2024-36006
Published: 2024-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

mlxsw: spectrum_acl_tcam: Fix incorrect list API usage

Both the function that migrates all the chunks within a region and the
function that migrates all the entries within a chunk call
list_first_entry() on the respective lists without checking that the
lists are not empty. This is incorrect usage of the API, which leads to
the following warning [1].

Fix by returning if the lists are empty as there is nothing to migrate
in this case.

[1]
WARNING: CPU: 0 PID: 6437 at drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c:1266 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x1f1/0>
Modules linked in:
CPU: 0 PID: 6437 Comm: kworker/0:37 Not tainted 6.9.0-rc3-custom-00883-g94a65f079ef6 #39
Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019
Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work
RIP: 0010:mlxsw_sp_acl_tcam_vchunk_migrate_all+0x1f1/0x2c0
[...]
Call Trace:
 <TASK>
 mlxsw_sp_acl_tcam_vregion_rehash_work+0x6c/0x4a0
 process_one_work+0x151/0x370
 worker_thread+0x2cb/0x3e0
 kthread+0xd0/0x100
 ret_from_fork+0x34/0x50
 ret_from_fork_asm+0x1a/0x30
 </TASK>
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/09846c2309b150b8ce4e0ce96f058197598fc530; https://git.kernel.org/stable/c/0b2c13b670b168e324e1cf109e67056a20fd610a; https://git.kernel.org/stable/c/4526a56e02da3725db979358964df9cd9c567154
CVE: CVE-2024-36007
Published: 2024-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

mlxsw: spectrum_acl_tcam: Fix warning during rehash

As previously explained, the rehash delayed work migrates filters from
one region to another. This is done by iterating over all chunks (all
the filters with the same priority) in the region and in each chunk
iterating over all the filters.

When the work runs out of credits it stores the current chunk and entry
as markers in the per-work context so that it would know where to resume
the migration from the next time the work is scheduled.

Upon error, the chunk marker is reset to NULL, but without resetting the
entry markers despite being relative to it. This can result in migration
being resumed from an entry that does not belong to the chunk being
migrated. In turn, this will eventually lead to a chunk being iterated
over as if it is an entry. Because of how the two structures happen to
be defined, this does not lead to KASAN splats, but to warnings such as
[1].

Fix by creating a helper that resets all the markers and call it from
all the places the currently only reset the chunk marker. For good
measures also call it when starting a completely new rehash. Add a
warning to avoid future cases.

[1]
WARNING: CPU: 7 PID: 1076 at drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_keys.c:407 mlxsw_afk_encode+0x242/0x2f0
Modules linked in:
CPU: 7 PID: 1076 Comm: kworker/7:24 Tainted: G        W          6.9.0-rc3-custom-00880-g29e61d91b77b #29
Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019
Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work
RIP: 0010:mlxsw_afk_encode+0x242/0x2f0
[...]
Call Trace:
 <TASK>
 mlxsw_sp_acl_atcam_entry_add+0xd9/0x3c0
 mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0
 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x109/0x290
 mlxsw_sp_acl_tcam_vregion_rehash_work+0x6c/0x470
 process_one_work+0x151/0x370
 worker_thread+0x2cb/0x3e0
 kthread+0xd0/0x100
 ret_from_fork+0x34/0x50
 </TASK>
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/039992b6d2df097c65f480dcf269de3d2656f573; https://git.kernel.org/stable/c/0b[PII_REDACTED]6b55cad901ac28d081e0f358e596; https://git.kernel.org/stable/c/17e9e0bbae652b9b2049e51699e93dfa60b2988d