rainbutterfly/cve_corpus huggingface dataset:
CVE-2024-47652 Insecure Authentication Vulnerability
This vulnerability exists in Shilpi Client Dashboard due to implementation of inadequate authentication mechanism in the login module wherein access to any users account is granted with just their corresponding mobile number. A remote attacker could exploit this vulnerability by providing mobile number of targeted user, to obtain complete access to the targeted user account.
Problem types: cwe_id: CWE-308
description: CWE-308: Use of Single-factor Authentication
Affected products: vendor: Shilpi Computers
product: Client Dashboard
default_status: unaffected
Credits: lang: en
value: This vulnerability is reported by Mohit Gadiya.
Published: 2024-10-04T12:13:22.614Z
CVE-2024-47653 Missing Authorization Vulnerability
This vulnerability exists in Shilpi Client Dashboard due to lack of authorization for modification and cancellation requests through certain API endpoints. An authenticated remote attacker could exploit this vulnerability by placing or cancelling requests through API request body leading to unauthorized modification of requests belonging to the other users.
Problem types: cwe_id: CWE-266
description: CWE-266: Incorrect Privilege Assignment
Affected products: vendor: Shilpi Computers
product: Client Dashboard
default_status: unaffected
Credits: lang: en
value: This vulnerability is reported by Mohit Gadiya.
Published: 2024-10-04T12:15:44.442Z
CVE-2024-47654 No Rate Limiting vulnerability
This vulnerability exists in Shilpi Client Dashboard due to lack of rate limiting and Captcha protection for OTP requests in certain API endpoint. An unauthenticated remote attacker could exploit this vulnerability by sending multiple OTP request through vulnerable API endpoints, which could lead to the OTP bombing on the targeted system.
Problem types: cwe_id: CWE-799
description: CWE-799: Improper Control of Interaction Frequency
Affected products: vendor: Shilpi Computers
product: Client Dashboard
default_status: unaffected
Credits: lang: en
value: This vulnerability is reported by Mohit Gadiya.
Published: 2024-10-04T12:18:18.257Z
CVE-2024-47655 Unrestricted File Upload Vulnerability
This vulnerability exists in the Shilpi Client Dashboard due to improper validation of files being uploaded other than the specified extension. An authenticated remote attacker could exploit this vulnerability by uploading malicious file, which could lead to remote code execution on targeted application.
Problem types: cwe_id: CWE-434
description: CWE-434 Unrestricted Upload of File with Dangerous Type
Affected products: vendor: Shilpi Computers
product: Client Dashboard
default_status: unaffected
Credits: lang: en
value: This vulnerability is reported by Mohit Gadiya.
Published: 2024-10-04T12:21:07.405Z
CVE-2024-47656 User Enumeration vulnerability
This vulnerability exists in Shilpi Client Dashboard due to missing restrictions for incorrect login attempts on its API based login. A remote attacker could exploit this vulnerability by conducting a brute force attack on password, which could lead to gain unauthorized access to other user accounts.
Problem types: cwe_id: CWE-307
description: CWE-307 Improper Restriction of Excessive Authentication Attempts
Affected products: vendor: Shilpi Computers
product: Client Dashboard
default_status: unaffected
Credits: lang: en
value: This vulnerability is reported by Mohit Gadiya.
Published: 2024-10-04T12:24:27.872Z
CVE-2024-47657 Improper Access Control Vulnerability
This vulnerability exists in the Shilpi Net Back Office due to improper access controls on certain API endpoints. An authenticated remote attacker could exploit this vulnerability by manipulating a parameter dfclientid through API request URLs which could lead to unauthorized access to sensitive information belonging to other users.
Problem types: cwe_id: CWE-639
description: CWE-639: Authorization Bypass Through User-Controlled Key
Affected products: vendor: Shilpi Computers
product: Net Back Office
default_status: unaffected
Credits: lang: en
value: This vulnerability is reported by Mohit Gadiya.
Published: 2024-10-04T12:30:46.271Z
CVE-2024-47658 crypto: stm32/cryp - call finalize with bh disabled
In the Linux kernel, the following vulnerability has been resolved:

crypto: stm32/cryp - call finalize with bh disabled

The finalize operation in interrupt mode produce a produces a spinlock
recursion warning. The reason is the fact that BH must be disabled
during this process.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-10-09T14:02:53.230Z
CVE-2024-47659 smack: tcp: ipv4, fix incorrect labeling
In the Linux kernel, the following vulnerability has been resolved:

smack: tcp: ipv4, fix incorrect labeling

Currently, Smack mirrors the label of incoming tcp/ipv4 connections:
when a label 'foo' connects to a label 'bar' with tcp/ipv4,
'foo' always gets 'foo' in returned ipv4 packets. So,
1) returned packets are incorrectly labeled ('foo' instead of 'bar')
2) 'bar' can write to 'foo' without being authorized to write.

Here is a scenario how to see this:

* Take two machines, let's call them C and S,
   with active Smack in the default state
   (no settings, no rules, no labeled hosts, only builtin labels)

* At S, add Smack rule 'foo bar w'
   (labels 'foo' and 'bar' are instantiated at S at this moment)

* At S, at label 'bar', launch a program
   that listens for incoming tcp/ipv4 connections

* From C, at label 'foo', connect to the listener at S.
   (label 'foo' is instantiated at C at this moment)
   Connection succeedes and works.

* Send some data in both directions.
* Collect network traffic of this connection.

All packets in both directions are labeled with the CIPSO
of the label 'foo'. Hence, label 'bar' writes to 'foo' without
being authorized, and even without ever being known at C.

If anybody cares: exactly the same happens with DCCP.

This behavior 1st manifested in release 2.6.29.4 (see Fixes below)
and it looks unintentional. At least, no explanation was provided.

I changed returned packes label into the 'bar',
to bring it into line with the Smack documentation claims.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-10-09T14:02:54.070Z
CVE-2024-47660 fsnotify: clear PARENT_WATCHED flags lazily
In the Linux kernel, the following vulnerability has been resolved:

fsnotify: clear PARENT_WATCHED flags lazily

In some setups directories can have many (usually negative) dentries.
Hence __fsnotify_update_child_dentry_flags() function can take a
significant amount of time. Since the bulk of this function happens
under inode->i_lock this causes a significant contention on the lock
when we remove the watch from the directory as the
__fsnotify_update_child_dentry_flags() call from fsnotify_recalc_mask()
races with __fsnotify_update_child_dentry_flags() calls from
__fsnotify_parent() happening on children. This can lead upto softlockup
reports reported by users.

Fix the problem by calling fsnotify_update_children_dentry_flags() to
set PARENT_WATCHED flags only when parent starts watching children.

When parent stops watching children, clear false positive PARENT_WATCHED
flags lazily in __fsnotify_parent() for each accessed child.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-10-09T14:02:54.884Z
CVE-2024-47661 drm/amd/display: Avoid overflow from uint32_t to uint8_t
In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Avoid overflow from uint32_t to uint8_t

[WHAT & HOW]
dmub_rb_cmd's ramping_boundary has size of uint8_t and it is assigned
0xFFFF. Fix it by changing it to uint8_t with value of 0xFF.

This fixes 2 INTEGER_OVERFLOW issues reported by Coverity.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-10-09T14:05:25.571Z
CVE-2024-47662 drm/amd/display: Remove register from DCN35 DMCUB diagnostic collection
In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Remove register from DCN35 DMCUB diagnostic collection

[Why]
These registers should not be read from driver and triggering the
security violation when DMCUB work times out and diagnostics are
collected blocks Z8 entry.

[How]
Remove the register read from DCN35.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-10-09T14:05:26.334Z
CVE-2024-47663 staging: iio: frequency: ad9834: Validate frequency parameter value
In the Linux kernel, the following vulnerability has been resolved:

staging: iio: frequency: ad9834: Validate frequency parameter value

In ad9834_write_frequency() clk_get_rate() can return 0. In such case
ad9834_calc_freqreg() call will lead to division by zero. Checking
'if (fout > (clk_freq / 2))' doesn't protect in case of 'fout' is 0.
ad9834_write_frequency() is called from ad9834_write(), where fout is
taken from text buffer, which can contain any value.

Modify parameters checking.

Found by Linux Verification Center (linuxtesting.org) with SVACE.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-10-09T14:13:56.514Z
CVE-2024-47664 spi: hisi-kunpeng: Add verification for the max_frequency provided by the firmware
In the Linux kernel, the following vulnerability has been resolved:

spi: hisi-kunpeng: Add verification for the max_frequency provided by the firmware

If the value of max_speed_hz is 0, it may cause a division by zero
error in hisi_calc_effective_speed().
The value of max_speed_hz is provided by firmware.
Firmware is generally considered as a trusted domain. However, as
division by zero errors can cause system failure, for defense measure,
the value of max_speed is validated here. So 0 is regarded as invalid
and an error code is returned.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-10-09T14:13:57.337Z
CVE-2024-47665 i3c: mipi-i3c-hci: Error out instead on BUG_ON() in IBI DMA setup
In the Linux kernel, the following vulnerability has been resolved:

i3c: mipi-i3c-hci: Error out instead on BUG_ON() in IBI DMA setup

Definitely condition dma_get_cache_alignment * defined value > 256
during driver initialization is not reason to BUG_ON(). Turn that to
graceful error out with -EINVAL.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-10-09T14:13:58.061Z
CVE-2024-47666 scsi: pm80xx: Set phy->enable_completion only when we wait for it
In the Linux kernel, the following vulnerability has been resolved:

scsi: pm80xx: Set phy->enable_completion only when we wait for it

pm8001_phy_control() populates the enable_completion pointer with a stack
address, sends a PHY_LINK_RESET / PHY_HARD_RESET, waits 300 ms, and
returns. The problem arises when a phy control response comes late.  After
300 ms the pm8001_phy_control() function returns and the passed
enable_completion stack address is no longer valid. Late phy control
response invokes complete() on a dangling enable_completion pointer which
leads to a kernel crash.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-10-09T14:13:58.849Z
CVE-2024-47667 PCI: keystone: Add workaround for Errata #i2037 (AM65x SR 1.0)
In the Linux kernel, the following vulnerability has been resolved:

PCI: keystone: Add workaround for Errata #i2037 (AM65x SR 1.0)

Errata #i2037 in AM65x/DRA80xM Processors Silicon Revision 1.0
(SPRZ452D_July 2018_Revised December 2019 [1]) mentions when an
inbound PCIe TLP spans more than two internal AXI 128-byte bursts,
the bus may corrupt the packet payload and the corrupt data may
cause associated applications or the processor to hang.

The workaround for Errata #i2037 is to limit the maximum read
request size and maximum payload size to 128 bytes. Add workaround
for Errata #i2037 here.

The errata and workaround is applicable only to AM65x SR 1.0 and
later versions of the silicon will have this fixed.

[1] -> https://www.ti.com/lit/er/sprz452i/sprz452i.pdf
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-10-09T14:13:59.522Z
CVE-2024-47668 lib/generic-radix-tree.c: Fix rare race in __genradix_ptr_alloc()
In the Linux kernel, the following vulnerability has been resolved:

lib/generic-radix-tree.c: Fix rare race in __genradix_ptr_alloc()

If we need to increase the tree depth, allocate a new node, and then
race with another thread that increased the tree depth before us, we'll
still have a preallocated node that might be used later.

If we then use that node for a new non-root node, it'll still have a
pointer to the old root instead of being zeroed - fix this by zeroing it
in the cmpxchg failure path.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-10-09T14:14:00.189Z
CVE-2024-47669 nilfs2: fix state management in error path of log writing function
In the Linux kernel, the following vulnerability has been resolved:

nilfs2: fix state management in error path of log writing function

After commit a694291a6211 ("nilfs2: separate wait function from
nilfs_segctor_write") was applied, the log writing function
nilfs_segctor_do_construct() was able to issue I/O requests continuously
even if user data blocks were split into multiple logs across segments,
but two potential flaws were introduced in its error handling.

First, if nilfs_segctor_begin_construction() fails while creating the
second or subsequent logs, the log writing function returns without
calling nilfs_segctor_abort_construction(), so the writeback flag set on
pages/folios will remain uncleared.  This causes page cache operations to
hang waiting for the writeback flag.  For example,
truncate_inode_pages_final(), which is called via nilfs_evict_inode() when
an inode is evicted from memory, will hang.

Second, the NILFS_I_COLLECTED flag set on normal inodes remain uncleared. 
As a result, if the next log write involves checkpoint creation, that's
fine, but if a partial log write is performed that does not, inodes with
NILFS_I_COLLECTED set are erroneously removed from the "sc_dirty_files"
list, and their data and b-tree blocks may not be written to the device,
corrupting the block mapping.

Fix these issues by uniformly calling nilfs_segctor_abort_construction()
on failure of each step in the loop in nilfs_segctor_do_construct(),
having it clean up logs and segment usages according to progress, and
correcting the conditions for calling nilfs_redirty_inodes() to ensure
that the NILFS_I_COLLECTED flag is cleared.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-10-09T14:14:01.139Z
CVE-2024-47670 ocfs2: add bounds checking to ocfs2_xattr_find_entry()
In the Linux kernel, the following vulnerability has been resolved:

ocfs2: add bounds checking to ocfs2_xattr_find_entry()

Add a paranoia check to make sure it doesn't stray beyond valid memory
region containing ocfs2 xattr entries when scanning for a match.  It will
prevent out-of-bound access in case of crafted images.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-10-09T14:49:11.938Z
CVE-2024-47671 USB: usbtmc: prevent kernel-usb-infoleak
In the Linux kernel, the following vulnerability has been resolved:

USB: usbtmc: prevent kernel-usb-infoleak

The syzbot reported a kernel-usb-infoleak in usbtmc_write,
we need to clear the structure before filling fields.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-10-09T14:49:12.703Z
CVE-2024-47673 wifi: iwlwifi: mvm: pause TCM when the firmware is stopped
In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: mvm: pause TCM when the firmware is stopped

Not doing so will make us send a host command to the transport while the
firmware is not alive, which will trigger a WARNING.

bad state = 0
WARNING: CPU: 2 PID: 17434 at drivers/net/wireless/intel/iwlwifi/iwl-trans.c:115 iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi]
RIP: 0010:iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi]
Call Trace:
 <TASK>
 iwl_mvm_send_cmd+0x40/0xc0 [iwlmvm]
 iwl_mvm_config_scan+0x198/0x260 [iwlmvm]
 iwl_mvm_recalc_tcm+0x730/0x11d0 [iwlmvm]
 iwl_mvm_tcm_work+0x1d/0x30 [iwlmvm]
 process_one_work+0x29e/0x640
 worker_thread+0x2df/0x690
 ? rescuer_thread+0x540/0x540
 kthread+0x192/0x1e0
 ? set_kthread_struct+0x90/0x90
 ret_from_fork+0x22/0x30
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-10-09T14:49:14.315Z
CVE-2024-47674 mm: avoid leaving partial pfn mappings around in error case
In the Linux kernel, the following vulnerability has been resolved:

mm: avoid leaving partial pfn mappings around in error case

As Jann points out, PFN mappings are special, because unlike normal
memory mappings, there is no lifetime information associated with the
mapping - it is just a raw mapping of PFNs with no reference counting of
a 'struct page'.

That's all very much intentional, but it does mean that it's easy to
mess up the cleanup in case of errors.  Yes, a failed mmap() will always
eventually clean up any partial mappings, but without any explicit
lifetime in the page table mapping itself, it's very easy to do the
error handling in the wrong order.

In particular, it's easy to mistakenly free the physical backing store
before the page tables are actually cleaned up and (temporarily) have
stale dangling PTE entries.

To make this situation less error-prone, just make sure that any partial
pfn mapping is torn down early, before any other error handling.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-10-15T10:48:33.481Z
CVE-2024-47675 bpf: Fix use-after-free in bpf_uprobe_multi_link_attach()
In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix use-after-free in bpf_uprobe_multi_link_attach()

If bpf_link_prime() fails, bpf_uprobe_multi_link_attach() goes to the
error_free label and frees the array of bpf_uprobe's without calling
bpf_uprobe_unregister().

This leaks bpf_uprobe->uprobe and worse, this frees bpf_uprobe->consumer
without removing it from the uprobe->consumers list.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-10-21T11:53:19.762Z
CVE-2024-47676 mm/hugetlb.c: fix UAF of vma in hugetlb fault pathway
In the Linux kernel, the following vulnerability has been resolved:

mm/hugetlb.c: fix UAF of vma in hugetlb fault pathway

Syzbot reports a UAF in hugetlb_fault().  This happens because
vmf_anon_prepare() could drop the per-VMA lock and allow the current VMA
to be freed before hugetlb_vma_unlock_read() is called.

We can fix this by using a modified version of vmf_anon_prepare() that
doesn't release the VMA lock on failure, and then release it ourselves
after hugetlb_vma_unlock_read().
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-10-21T11:53:20.482Z
CVE-2024-47677 exfat: resolve memory leak from exfat_create_upcase_table()
In the Linux kernel, the following vulnerability has been resolved:

exfat: resolve memory leak from exfat_create_upcase_table()

If exfat_load_upcase_table reaches end and returns -EINVAL,
allocated memory doesn't get freed and while
exfat_load_default_upcase_table allocates more memory, leading to a
memory leak.

Here's link to syzkaller crash report illustrating this issue:
https://syzkaller.appspot.com/text?tag=CrashReport&x=1406c201980000
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-10-21T11:53:21.138Z
CVE-2024-47678 icmp: change the order of rate limits
In the Linux kernel, the following vulnerability has been resolved:

icmp: change the order of rate limits

ICMP messages are ratelimited :

After the blamed commits, the two rate limiters are applied in this order:

1) host wide ratelimit (icmp_global_allow())

2) Per destination ratelimit (inetpeer based)

In order to avoid side-channels attacks, we need to apply
the per destination check first.

This patch makes the following change :

1) icmp_global_allow() checks if the host wide limit is reached.
   But credits are not yet consumed. This is deferred to 3)

2) The per destination limit is checked/updated.
   This might add a new node in inetpeer tree.

3) icmp_global_consume() consumes tokens if prior operations succeeded.

This means that host wide ratelimit is still effective
in keeping inetpeer tree small even under DDOS.

As a bonus, I removed icmp_global.lock as the fast path
can use a lock-free operation.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-10-21T11:53:21.814Z
CVE-2024-47679 vfs: fix race between evice_inodes() and find_inode()&iput()
In the Linux kernel, the following vulnerability has been resolved:

vfs: fix race between evice_inodes() and find_inode()&iput()

Hi, all

Recently I noticed a bug[1] in btrfs, after digged it into
and I believe it'a race in vfs.

Let's assume there's a inode (ie ino 261) with i_count 1 is
called by iput(), and there's a concurrent thread calling
generic_shutdown_super().

cpu0:                              cpu1:
iput() // i_count is 1
  ->spin_lock(inode)
  ->dec i_count to 0
  ->iput_final()                    generic_shutdown_super()
    ->__inode_add_lru()               ->evict_inodes()
      // cause some reason[2]           ->if (atomic_read(inode->i_count)) continue;
      // return before                  // inode 261 passed the above check
      // list_lru_add_obj()             // and then schedule out
   ->spin_unlock()
// note here: the inode 261
// was still at sb list and hash list,
// and I_FREEING|I_WILL_FREE was not been set

btrfs_iget()
  // after some function calls
  ->find_inode()
    // found the above inode 261
    ->spin_lock(inode)
   // check I_FREEING|I_WILL_FREE
   // and passed
      ->__iget()
    ->spin_unlock(inode)                // schedule back
                                        ->spin_lock(inode)
                                        // check (I_NEW|I_FREEING|I_WILL_FREE) flags,
                                        // passed and set I_FREEING
iput()                                  ->spin_unlock(inode)
  ->spin_lock(inode)			  ->evict()
  // dec i_count to 0
  ->iput_final()
    ->spin_unlock()
    ->evict()

Now, we have two threads simultaneously evicting
the same inode, which may trigger the BUG(inode->i_state & I_CLEAR)
statement both within clear_inode() and iput().

To fix the bug, recheck the inode->i_count after holding i_lock.
Because in the most scenarios, the first check is valid, and
the overhead of spin_lock() can be reduced.

If there is any misunderstanding, please let me know, thanks.

[1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/
[2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable()
return false when I reproduced the bug.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-10-21T11:53:22.469Z