Show filters
6,560 Total Results
Displaying 541-550 of 6,560
Sort by:
Attacker Value
Unknown
CVE-2024-50208
Disclosure Date: November 08, 2024 (last updated February 27, 2025)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/bnxt_re: Fix a bug while setting up Level-2 PBL pages
Avoid memory corruption while setting up Level-2 PBL pages for the non MR
resources when num_pages > 256K.
There will be a single PDE page address (contiguous pages in the case of >
PAGE_SIZE), but, current logic assumes multiple pages, leading to invalid
memory access after 256K PBL entries in the PDE.
0
Attacker Value
Unknown
CVE-2024-50207
Disclosure Date: November 08, 2024 (last updated February 27, 2025)
In the Linux kernel, the following vulnerability has been resolved:
ring-buffer: Fix reader locking when changing the sub buffer order
The function ring_buffer_subbuf_order_set() updates each
ring_buffer_per_cpu and installs new sub buffers that match the requested
page order. This operation may be invoked concurrently with readers that
rely on some of the modified data, such as the head bit (RB_PAGE_HEAD), or
the ring_buffer_per_cpu.pages and reader_page pointers. However, no
exclusive access is acquired by ring_buffer_subbuf_order_set(). Modifying
the mentioned data while a reader also operates on them can then result in
incorrect memory access and various crashes.
Fix the problem by taking the reader_lock when updating a specific
ring_buffer_per_cpu in ring_buffer_subbuf_order_set().
0
Attacker Value
Unknown
CVE-2024-50206
Disclosure Date: November 08, 2024 (last updated February 27, 2025)
In the Linux kernel, the following vulnerability has been resolved:
net: ethernet: mtk_eth_soc: fix memory corruption during fq dma init
The loop responsible for allocating up to MTK_FQ_DMA_LENGTH buffers must
only touch as many descriptors, otherwise it ends up corrupting unrelated
memory. Fix the loop iteration count accordingly.
0
Attacker Value
Unknown
CVE-2024-50205
Disclosure Date: November 08, 2024 (last updated February 27, 2025)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: firewire-lib: Avoid division by zero in apply_constraint_to_size()
The step variable is initialized to zero. It is changed in the loop,
but if it's not changed it will remain zero. Add a variable check
before the division.
The observed behavior was introduced by commit 826b5de90c0b
("ALSA: firewire-lib: fix insufficient PCM rule for period/buffer size"),
and it is difficult to show that any of the interval parameters will
satisfy the snd_interval_test() condition with data from the
amdtp_rate_table[] table.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
0
Attacker Value
Unknown
CVE-2024-50204
Disclosure Date: November 08, 2024 (last updated November 20, 2024)
In the Linux kernel, the following vulnerability has been resolved:
fs: don't try and remove empty rbtree node
When copying a namespace we won't have added the new copy into the
namespace rbtree until after the copy succeeded. Calling free_mnt_ns()
will try to remove the copy from the rbtree which is invalid. Simply
free the namespace skeleton directly.
0
Attacker Value
Unknown
CVE-2024-50203
Disclosure Date: November 08, 2024 (last updated February 27, 2025)
In the Linux kernel, the following vulnerability has been resolved:
bpf, arm64: Fix address emission with tag-based KASAN enabled
When BPF_TRAMP_F_CALL_ORIG is enabled, the address of a bpf_tramp_image
struct on the stack is passed during the size calculation pass and
an address on the heap is passed during code generation. This may
cause a heap buffer overflow if the heap address is tagged because
emit_a64_mov_i64() will emit longer code than it did during the size
calculation pass. The same problem could occur without tag-based
KASAN if one of the 16-bit words of the stack address happened to
be all-ones during the size calculation pass. Fix the problem by
assuming the worst case (4 instructions) when calculating the size
of the bpf_tramp_image address emission.
0
Attacker Value
Unknown
CVE-2024-50202
Disclosure Date: November 08, 2024 (last updated February 27, 2025)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: propagate directory read errors from nilfs_find_entry()
Syzbot reported that a task hang occurs in vcs_open() during a fuzzing
test for nilfs2.
The root cause of this problem is that in nilfs_find_entry(), which
searches for directory entries, ignores errors when loading a directory
page/folio via nilfs_get_folio() fails.
If the filesystem images is corrupted, and the i_size of the directory
inode is large, and the directory page/folio is successfully read but
fails the sanity check, for example when it is zero-filled,
nilfs_check_folio() may continue to spit out error messages in bursts.
Fix this issue by propagating the error to the callers when loading a
page/folio fails in nilfs_find_entry().
The current interface of nilfs_find_entry() and its callers is outdated
and cannot propagate error codes such as -EIO and -ENOMEM returned via
nilfs_find_entry(), so fix it together.
0
Attacker Value
Unknown
CVE-2024-50201
Disclosure Date: November 08, 2024 (last updated November 20, 2024)
In the Linux kernel, the following vulnerability has been resolved:
drm/radeon: Fix encoder->possible_clones
Include the encoder itself in its possible_clones bitmask.
In the past nothing validated that drivers were populating
possible_clones correctly, but that changed in commit
74d2aacbe840 ("drm: Validate encoder->possible_clones").
Looks like radeon never got the memo and is still not
following the rules 100% correctly.
This results in some warnings during driver initialization:
Bogus possible_clones: [ENCODER:46:TV-46] possible_clones=0x4 (full encoder mask=0x7)
WARNING: CPU: 0 PID: 170 at drivers/gpu/drm/drm_mode_config.c:615 drm_mode_config_validate+0x113/0x39c
...
(cherry picked from commit 3b6e7d40649c0d75572039aff9d0911864c689db)
0
Attacker Value
Unknown
CVE-2024-50198
Disclosure Date: November 08, 2024 (last updated February 27, 2025)
In the Linux kernel, the following vulnerability has been resolved:
iio: light: veml6030: fix IIO device retrieval from embedded device
The dev pointer that is received as an argument in the
in_illuminance_period_available_show function references the device
embedded in the IIO device, not in the i2c client.
dev_to_iio_dev() must be used to accessthe right data. The current
implementation leads to a segmentation fault on every attempt to read
the attribute because indio_dev gets a NULL assignment.
This bug has been present since the first appearance of the driver,
apparently since the last version (V6) before getting applied. A
constant attribute was used until then, and the last modifications might
have not been tested again.
0
Attacker Value
Unknown
CVE-2024-50197
Disclosure Date: November 08, 2024 (last updated February 27, 2025)
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: intel: platform: fix error path in device_for_each_child_node()
The device_for_each_child_node() loop requires calls to
fwnode_handle_put() upon early returns to decrement the refcount of
the child node and avoid leaking memory if that error path is triggered.
There is one early returns within that loop in
intel_platform_pinctrl_prepare_community(), but fwnode_handle_put() is
missing.
Instead of adding the missing call, the scoped version of the loop can
be used to simplify the code and avoid mistakes in the future if new
early returns are added, as the child node is only used for parsing, and
it is never assigned.
0