deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2024-46896
Published: 2025-01-11
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: don't access invalid sched

Since 2320c9e6a768 ("drm/sched: memset() 'job' in drm_sched_job_init()")
accessing job->base.sched can produce unexpected results as the initialisation
of (*job)->base.sched done in amdgpu_job_alloc is overwritten by the
memset.

This commit fixes an issue when a CS would fail validation and would
be rejected after job->num_ibs is incremented. In this case,
amdgpu_ib_free(ring->adev, ...) will be called, which would crash the
machine because the ring value is bogus.

To fix this, pass a NULL pointer to amdgpu_ib_free(): we can do this
because the device is actually not used in this function.

The next commit will remove the ring argument completely.

(cherry picked from commit 2ae520cb12831d264ceb97c61f72c59d33c0dbd7)
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/65501a4fd84ecdc0af863dbb37759242aab9f2dd; https://git.kernel.org/stable/c/67291d601f2b032062b1b2f60ffef1b63e10094c; https://git.kernel.org/stable/c/a93b1020eb9386d7da[PII_REDACTED]b10079c076a
CVE: CVE-2024-47141
Published: 2025-01-11
Description: In the Linux kernel, the following vulnerability has been resolved:

pinmux: Use sequential access to access desc->pinmux data

When two client of the same gpio call pinctrl_select_state() for the
same functionality, we are seeing NULL pointer issue while accessing
desc->mux_owner.

Let's say two processes A, B executing in pin_request() for the same pin
and process A updates the desc->mux_usecount but not yet updated the
desc->mux_owner while process B see the desc->mux_usecount which got
updated by A path and further executes strcmp and while accessing
desc->mux_owner it crashes with NULL pointer.

Serialize the access to mux related setting with a mutex lock.

	cpu0 (process A)			cpu1(process B)

pinctrl_select_state() {		  pinctrl_select_state() {
  pin_request() {				pin_request() {
  ...
						 ....
    } else {
         desc->mux_usecount++;
    						desc->mux_usecount && strcmp(desc->mux_owner, owner)) {

         if (desc->mux_usecount > 1)
               return 0;
         desc->mux_owner = owner;

  }						}
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667, CWE-667
References: https://git.kernel.org/stable/c/2da32aed4a97ca1d70fb8b77926f72f30ce5fb4b; https://git.kernel.org/stable/c/5a3e85c3c397c781393ea5fb2f45b1f60f8a4e6e; https://git.kernel.org/stable/c/c11e2ec9a780f54982a187ee10ffd1b810715c85
CVE: CVE-2024-47143
Published: 2025-01-11
Description: In the Linux kernel, the following vulnerability has been resolved:

dma-debug: fix a possible deadlock on radix_lock

radix_lock() shouldn't be held while holding dma_hash_entry[idx].lock
otherwise, there's a possible deadlock scenario when
dma debug API is called holding rq_lock():

CPU0                   CPU1                       CPU2
dma_free_attrs()
check_unmap()          add_dma_entry()            __schedule() //out
                                                  (A) rq_lock()
get_hash_bucket()
(A) dma_entry_hash
                                                  check_sync()
                       (A) radix_lock()           (W) dma_entry_hash
dma_entry_free()
(W) radix_lock()
                       // CPU2's one
                       (W) rq_lock()

CPU1 situation can happen when it extending radix tree and
it tries to wake up kswapd via wake_all_kswapd().

CPU2 situation can happen while perf_event_task_sched_out()
(i.e. dma sync operation is called while deleting perf_event using
 etm and etr tmc which are Arm Coresight hwtracing driver backends).

To remove this possible situation, call dma_entry_free() after
put_hash_bucket() in check_unmap().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667, CWE-667
References: https://git.kernel.org/stable/c/3ccce34a5c3f5c9541108a451657ade621524b32; https://git.kernel.org/stable/c/7543c3e3b9b88212fcd0aaf5cab5588797bdc7de; https://git.kernel.org/stable/c/8c1b4fea8d62285f5e1a8194889b39661608bd8a
CVE: CVE-2024-47408
Published: 2025-01-11
Description: In the Linux kernel, the following vulnerability has been resolved:

net/smc: check smcd_v2_ext_offset when receiving proposal msg

When receiving proposal msg in server, the field smcd_v2_ext_offset in
proposal msg is from the remote client and can not be fully trusted.
Once the value of smcd_v2_ext_offset exceed the max value, there has
the chance to access wrong address, and crash may happen.

This patch checks the value of smcd_v2_ext_offset before using it.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/48d5a8a304a643613dab376a278f29d3e22f7c34; https://git.kernel.org/stable/c/935caf324b445fe73d7708fae6f7176fb243f357; https://git.kernel.org/stable/c/9ab332deb671d8f7e66d82a2ff2b3f715bc3a4ad
CVE: CVE-2024-47794
Published: 2025-01-11
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Prevent tailcall infinite loop caused by freplace

There is a potential infinite loop issue that can occur when using a
combination of tail calls and freplace.

In an upcoming selftest, the attach target for entry_freplace of
tailcall_freplace.c is subprog_tc of tc_bpf2bpf.c, while the tail call in
entry_freplace leads to entry_tc. This results in an infinite loop:

entry_tc -> subprog_tc -> entry_freplace --tailcall-> entry_tc.

The problem arises because the tail_call_cnt in entry_freplace resets to
zero each time entry_freplace is executed, causing the tail call mechanism
to never terminate, eventually leading to a kernel panic.

To fix this issue, the solution is twofold:

1. Prevent updating a program extended by an freplace program to a
   prog_array map.
2. Prevent extending a program that is already part of a prog_array map
   with an freplace program.

This ensures that:

* If a program or its subprogram has been extended by an freplace program,
  it can no longer be updated to a prog_array map.
* If a program has been added to a prog_array map, neither it nor its
  subprograms can be extended by an freplace program.

Moreover, an extension program should not be tailcalled. As such, return
-EINVAL if the program has a type of BPF_PROG_TYPE_EXT when adding it to a
prog_array map.

Additionally, fix a minor code style issue by replacing eight spaces with a
tab for proper formatting.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-835
References: https://git.kernel.org/stable/c/987aa730bad3e1ef66d9f30182294daa78f6387d; https://git.kernel.org/stable/c/d6083f040d5d8f8d748462c77e90547097df936e
CVE: CVE-2024-47809
Published: 2025-01-11
Description: In the Linux kernel, the following vulnerability has been resolved:

dlm: fix possible lkb_resource null dereference

This patch fixes a possible null pointer dereference when this function is
called from request_lock() as lkb->lkb_resource is not assigned yet,
only after validate_lock_args() by calling attach_lkb(). Another issue
is that a resource name could be a non printable bytearray and we cannot
assume to be ASCII coded.

The log functionality is probably never being hit when DLM is used in
normal way and no debug logging is enabled. The null pointer dereference
can only occur on a new created lkb that does not have the resource
assigned yet, it probably never hits the null pointer dereference but we
should be sure that other changes might not change this behaviour and we
actually can hit the mentioned null pointer dereference.

In this patch we just drop the printout of the resource name, the lkb id
is enough to make a possible connection to a resource name if this
exists.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/2db11504ef82a60c1a2063ba7431a5cd013ecfcb; https://git.kernel.org/stable/c/6fbdc3980b70e9c1c86eccea7d5ee68108008fa7; https://git.kernel.org/stable/c/8d55ce46dd543c6965970ce70c22c3076dd35b1e
CVE: CVE-2024-48873
Published: 2025-01-11
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: rtw89: check return value of ieee80211_probereq_get() for RNR

The return value of ieee80211_probereq_get() might be NULL, so check it
before using to avoid NULL pointer access.

Addresses-Coverity-ID: 1529805 ("Dereference null return value")
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/1a0f54cb3fea5d087440b2bae03202c445156a8d; https://git.kernel.org/stable/c/630d5d8f2bf6b340202b6bc2c05d794bbd8e4c1c; https://git.kernel.org/stable/c/7296e5611adb2c619bd7bd3817ddde7ba865ef17
CVE: CVE-2024-48876
Published: 2025-01-11
Description: In the Linux kernel, the following vulnerability has been resolved:

stackdepot: fix stack_depot_save_flags() in NMI context

Per documentation, stack_depot_save_flags() was meant to be usable from
NMI context if STACK_DEPOT_FLAG_CAN_ALLOC is unset.  However, it still
would try to take the pool_lock in an attempt to save a stack trace in the
current pool (if space is available).

This could result in deadlock if an NMI is handled while pool_lock is
already held.  To avoid deadlock, only try to take the lock in NMI context
and give up if unsuccessful.

The documentation is fixed to clearly convey this.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/031e04bdc834cda3b054ef6b698503b2b97e8186; https://git.kernel.org/stable/c/9bfeeeff2c92b9dd261198b601b45bde4c529841
CVE: CVE-2024-48881
Published: 2025-01-11
Description: In the Linux kernel, the following vulnerability has been resolved:

bcache: revert replacing IS_ERR_OR_NULL with IS_ERR again

Commit 028ddcac477b ("bcache: Remove unnecessary NULL point check in
node allocations") leads a NULL pointer deference in cache_set_flush().

1721         if (!IS_ERR_OR_NULL(c->root))
1722                 list_add(&c->root->list, &c->btree_cache);

>From the above code in cache_set_flush(), if previous registration code
fails before allocating c->root, it is possible c->root is NULL as what
it is initialized. __bch_btree_node_alloc() never returns NULL but
c->root is possible to be NULL at above line 1721.

This patch replaces IS_ERR() by IS_ERR_OR_NULL() to fix this.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/336e30f32ae7c043fde0f6fa21586ff30bea9fe2; https://git.kernel.org/stable/c/4379c5828492a4c2a651c8f826a01453bd2b80b0; https://git.kernel.org/stable/c/[PII_REDACTED]ffbf81975251b3526b890ba027b715
CVE: CVE-2024-49568
Published: 2025-01-11
Description: In the Linux kernel, the following vulnerability has been resolved:

net/smc: check v2_ext_offset/eid_cnt/ism_gid_cnt when receiving proposal msg

When receiving proposal msg in server, the fields v2_ext_offset/
eid_cnt/ism_gid_cnt in proposal msg are from the remote client
and can not be fully trusted. Especially the field v2_ext_offset,
once exceed the max value, there has the chance to access wrong
address, and crash may happen.

This patch checks the fields v2_ext_offset/eid_cnt/ism_gid_cnt
before using them.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/295a92e3df32e72aff0f4bc25c310e349d07ffbf; https://git.kernel.org/stable/c/42f6beb2d[PII_REDACTED]b5f8115a4e3fa695d2a6c; https://git.kernel.org/stable/c/7863c9f3d24ba49dbead7e03dfbe40deb5888fdf
CVE: CVE-2024-49569
Published: 2025-01-11
Description: In the Linux kernel, the following vulnerability has been resolved:

nvme-rdma: unquiesce admin_q before destroy it

Kernel will hang on destroy admin_q while we create ctrl failed, such
as following calltrace:

PID: 23644    TASK: ff2d52b40f439fc0  CPU: 2    COMMAND: "nvme"
 #0 [ff61d23de260fb78] __schedule at ffffffff8323bc15
 #1 [ff61d23de260fc08] schedule at ffffffff8323c014
 #2 [ff61d23de260fc28] blk_mq_freeze_queue_wait at ffffffff82a3dba1
 #3 [ff61d23de260fc78] blk_freeze_queue at ffffffff82a4113a
 #4 [ff61d23de260fc90] blk_cleanup_queue at ffffffff82a33006
 #5 [ff61d23de260fcb0] nvme_rdma_destroy_admin_queue at ffffffffc12686ce
 #6 [ff61d23de260fcc8] nvme_rdma_setup_ctrl at ffffffffc1268ced
 #7 [ff61d23de260fd28] nvme_rdma_create_ctrl at ffffffffc126919b
 #8 [ff61d23de260fd68] nvmf_dev_write at ffffffffc024f362
 #9 [ff61d23de260fe38] vfs_write at ffffffff827d5f25
    RIP: 00007fda7891d574  RSP: 00007ffe2ef06958  RFLAGS: 00000202
    RAX: ffffffffffffffda  RBX: 000055e8122a4d90  RCX: 00007fda7891d574
    RDX:[PII_REDACTED]00012b  RSI: 000055e8122a4d90  RDI: [PII_REDACTED]
    RBP: 00007ffe2ef079c0   R8:[PII_REDACTED]00012b   R9: 000055e8122a4d90
    R10: [PII_REDACTED]  R11: [PII_REDACTED]  R12: [PII_REDACTED]
    R13: 000055e8122923c0  R14:[PII_REDACTED]00012b  R15: 00007fda78a54500
    ORIG_RAX: [PII_REDACTED]  CS: 0033  SS: 002b

This due to we have quiesced admi_q before cancel requests, but forgot
to unquiesce before destroy it, as a result we fail to drain the
pending requests, and hang on blk_mq_freeze_queue_wait() forever. Here
try to reuse nvme_rdma_teardown_admin_queue() to fix this issue and
simplify the code.
CVSS Score: 5.7 (MEDIUM)
References: https://git.kernel.org/stable/c/05b436f3cf65c957eff86c5ea5ddfa2604b32c63; https://git.kernel.org/stable/c/427036030f4d796533dcadba9b845896cb6c10a7; https://git.kernel.org/stable/c/5858b687559809f05393af745cbadf06dee61295
CVE: CVE-2024-49571
Published: 2025-01-11
Description: In the Linux kernel, the following vulnerability has been resolved:

net/smc: check iparea_offset and ipv6_prefixes_cnt when receiving proposal msg

When receiving proposal msg in server, the field iparea_offset
and the field ipv6_prefixes_cnt in proposal msg are from the
remote client and can not be fully trusted. Especially the
field iparea_offset, once exceed the max value, there has the
chance to access wrong address, and crash may happen.

This patch checks iparea_offset and ipv6_prefixes_cnt before using them.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/47ce46349672a7e0c361bfe39ed0b22e824ef4fb; https://git.kernel.org/stable/c/62056d1592e63d85e82357ee2ae6a6a294f440b0; https://git.kernel.org/stable/c/846bada23bfcdeb83621b045ed85dc06c7833ff0
CVE: CVE-2024-49573
Published: 2025-01-11
Description: In the Linux kernel, the following vulnerability has been resolved:

sched/fair: Fix NEXT_BUDDY

Adam reports that enabling NEXT_BUDDY insta triggers a WARN in
pick_next_entity().

Moving clear_buddies() up before the delayed dequeue bits ensures
no ->next buddy becomes delayed. Further ensure no new ->next buddy
ever starts as delayed.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/493afbd187c4c9cc1642792c0d9ba400c3d6d90d; https://git.kernel.org/stable/c/5dbe6816c49197677a5ecce749bd99929da147da
CVE: CVE-2024-50051
Published: 2025-01-11
Description: In the Linux kernel, the following vulnerability has been resolved:

spi: mpc52xx: Add cancel_work_sync before module remove

If we remove the module which will call mpc52xx_spi_remove
it will free 'ms' through spi_unregister_controller.
while the work ms->work will be used. The sequence of operations
that may lead to a UAF bug.

Fix it by ensuring that the work is canceled before proceeding with
the cleanup in mpc52xx_spi_remove.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416, CWE-416
References: https://git.kernel.org/stable/c/373d55a47dc662e5e30d12ad5d334312f757c1f1; https://git.kernel.org/stable/c/90b72189de2cddacb26250579da0510b29a8b82b; https://git.kernel.org/stable/c/984836621aad98802d92c4a3047114cf518074c8
CVE: CVE-2024-51729
Published: 2025-01-11
Description: In the Linux kernel, the following vulnerability has been resolved:

mm: use aligned address in copy_user_gigantic_page()

In current kernel, hugetlb_wp() calls copy_user_large_folio() with the
fault address.  Where the fault address may be not aligned with the huge
page size.  Then, copy_user_large_folio() may call
copy_user_gigantic_page() with the address, while
copy_user_gigantic_page() requires the address to be huge page size
aligned.  So, this may cause memory corruption or information leak,
addtional, use more obvious naming 'addr_hint' instead of 'addr' for
copy_user_gigantic_page().
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/cb12d61361ce769672c7c7bd[PII_REDACTED]8cdd8b; https://git.kernel.org/stable/c/f5d09de9f1bf9674c6418ff10d0a40cfe29268e1
CVE: CVE-2024-52319
Published: 2025-01-11
Description: In the Linux kernel, the following vulnerability has been resolved:

mm: use aligned address in clear_gigantic_page()

In current kernel, hugetlb_no_page() calls folio_zero_user() with the
fault address.  Where the fault address may be not aligned with the huge
page size.  Then, folio_zero_user() may call clear_gigantic_page() with
the address, while clear_gigantic_page() requires the address to be huge
page size aligned.  So, this may cause memory corruption or information
leak, addtional, use more obvious naming 'addr_hint' instead of 'addr' for
clear_gigantic_page().
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/8aca2bc96c833ba695ede7a45ad7784c836a262e; https://git.kernel.org/stable/c/b79b6fe0737f233f0be1465052b7f0e75f324735
CVE: CVE-2024-52332
Published: 2025-01-11
Description: In the Linux kernel, the following vulnerability has been resolved:

igb: Fix potential invalid memory access in igb_init_module()

The pci_register_driver() can fail and when this happened, the dca_notifier
needs to be unregistered, otherwise the dca_notifier can be called when
igb fails to install, resulting to invalid memory access.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/0566f83d206c7a864abcd741fe39d6e0ae5eef29; https://git.kernel.org/stable/c/[PII_REDACTED]dfadc351162dbaea1945c57eebdf36; https://git.kernel.org/stable/c/4fe517643f529e805bb6b890a4331c100e8f2484
CVE: CVE-2024-53682
Published: 2025-01-11
Description: In the Linux kernel, the following vulnerability has been resolved:

regulator: axp20x: AXP717: set ramp_delay

AXP717 datasheet says that regulator ramp delay is 15.625 us/step,
which is 10mV in our case.

Add a AXP_DESC_RANGES_DELAY macro and update AXP_DESC_RANGES macro to
expand to AXP_DESC_RANGES_DELAY with ramp_delay = 0

For DCDC4, steps is 100mv

Add a AXP_DESC_DELAY macro and update AXP_DESC macro to
expand to AXP_DESC_DELAY with ramp_delay = 0

This patch fix crashes when using CPU DVFS.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/10eb845a87193ef922cd002e0ff4f4759c1e918d; https://git.kernel.org/stable/c/f07ae52f5cf6a5584fdf7c8c652f027d90bc8b74
CVE: CVE-2024-53685
Published: 2025-01-11
Description: In the Linux kernel, the following vulnerability has been resolved:

ceph: give up on paths longer than PATH_MAX

If the full path to be built by ceph_mdsc_build_path() happens to be
longer than PATH_MAX, then this function will enter an endless (retry)
loop, effectively blocking the whole task.  Most of the machine
becomes unusable, making this a very simple and effective DoS
vulnerability.

I cannot imagine why this retry was ever implemented, but it seems
rather useless and harmful to me.  Let's remove it and fail with
ENAMETOOLONG instead.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-835
References: https://git.kernel.org/stable/c/0f2b2d9e881c90402dbe28f9ba831775b7992e1f; https://git.kernel.org/stable/c/550f7ca98ee028a606aa75705a7e77b1bd11720f; https://git.kernel.org/stable/c/99a37ab76a315c8307eb5b0dc095d8ad9d8efeaa
CVE: CVE-2024-53689
Published: 2025-01-11
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-53690
Published: 2025-01-11
Description: In the Linux kernel, the following vulnerability has been resolved:

nilfs2: prevent use of deleted inode

syzbot reported a WARNING in nilfs_rmdir. [1]

Because the inode bitmap is corrupted, an inode with an inode number that
should exist as a ".nilfs" file was reassigned by nilfs_mkdir for "file0",
causing an inode duplication during execution.  And this causes an
underflow of i_nlink in rmdir operations.

The inode is used twice by the same task to unmount and remove directories
".nilfs" and "file0", it trigger warning in nilfs_rmdir.

Avoid to this issue, check i_nlink in nilfs_iget(), if it is 0, it means
that this inode has been deleted, and iput is executed to reclaim it.

[1]
WARNING: CPU: 1 PID: 5824 at fs/inode.c:407 drop_nlink+0xc4/0x110 fs/inode.c:407
...
Call Trace:
 <TASK>
 nilfs_rmdir+0x1b0/0x250 fs/nilfs2/namei.c:342
 vfs_rmdir+0x3a3/0x510 fs/namei.c:4394
 do_rmdir+0x3b5/0x580 fs/namei.c:4453
 __do_sys_rmdir fs/namei.c:4472 [inline]
 __se_sys_rmdir fs/namei.c:4470 [inline]
 __x64_sys_rmdir+0x47/0x50 fs/namei.c:4470
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/284760b320a0bac411b[PII_REDACTED]707dccb12b; https://git.kernel.org/stable/c/55e4baa0d32f0530ddc64c26620e1f2f8fa2724c; https://git.kernel.org/stable/c/5d4ed71327b0b5f3b179a19dc3c06be9509ab3db
CVE: CVE-2024-54193
Published: 2025-01-11
Description: In the Linux kernel, the following vulnerability has been resolved:

accel/ivpu: Fix WARN in ivpu_ipc_send_receive_internal()

Move pm_runtime_set_active() to ivpu_pm_init() so when
ivpu_ipc_send_receive_internal() is executed before ivpu_pm_enable()
it already has correct runtime state, even if last resume was
not successful.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0f6482caa6acdfdfc744db7430771fe7e6c4e787; https://git.kernel.org/stable/c/578874b2bb947e047708f4df286e4ff1ba6be3ad
CVE: CVE-2024-54455
Published: 2025-01-11
Description: In the Linux kernel, the following vulnerability has been resolved:

accel/ivpu: Fix general protection fault in ivpu_bo_list()

Check if ctx is not NULL before accessing its fields.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/4b2efb9db0c22a130bbd1275e489b42c02d08050; https://git.kernel.org/stable/c/a1e597ee5920a6aabdf4dfc3bf76e55e1b115e23
CVE: CVE-2024-54680
Published: 2025-01-11
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-54683
Published: 2025-01-11
Description: In the Linux kernel, the following vulnerability has been resolved:

netfilter: IDLETIMER: Fix for possible ABBA deadlock

Deletion of the last rule referencing a given idletimer may happen at
the same time as a read of its file in sysfs:

| ======================================================
| WARNING: possible circular locking dependency detected
| 6.12.0-rc7-01692-g5e9a28f41134-dirty #594 Not tainted
| ------------------------------------------------------
| iptables/3303 is trying to acquire lock:
| ffff8881057e04b8 (kn->active#48){++++}-{0:0}, at: __kernfs_remove+0x20
|
| but task is already holding lock:
| ffffffffa0249068 (list_mutex){+.+.}-{3:3}, at: idletimer_tg_destroy_v]
|
| which lock already depends on the new lock.

A simple reproducer is:

| #!/bin/bash
|
| while true; do
|         iptables -A INPUT -i foo -j IDLETIMER --timeout 10 --label "testme"
|         iptables -D INPUT -i foo -j IDLETIMER --timeout 10 --label "testme"
| done &
| while true; do
|         cat /sys/class/xt_idletimer/timers/testme >/dev/null
| done

Avoid this by freeing list_mutex right after deleting the element from
the list, then continuing with the teardown.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667, CWE-667
References: https://git.kernel.org/stable/c/45fe76573a2557f632e248cc141342233f422b9a; https://git.kernel.org/stable/c/8c2c8445cda8f59c38dec7dc10509bcb23ae26a0; https://git.kernel.org/stable/c/f36b01994d68ffc253c8296e2228dfe6e6431c03
CVE: CVE-2024-55639
Published: 2025-01-11
Description: In the Linux kernel, the following vulnerability has been resolved:

net: renesas: rswitch: avoid use-after-put for a device tree node

The device tree node saved in the rswitch_device structure is used at
several driver locations. So passing this node to of_node_put() after
the first use is wrong.

Move of_node_put() for this node to exit paths.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/66b7e9f85b8459c823b11e9af69dbf4be5eb6be8; https://git.kernel.org/stable/c/92007a28f95413058a7268dc84e5f44b700165d1; https://git.kernel.org/stable/c/bf8c6755f02029d1eddc3ff19b870240f054afc7