huzaifas-sidhpurwala/security-commit huggingface dataset:
CVE-2024-49927: kernel: x86/ioapic: Handle allocation failures gracefully
Component: kernel
Severity: Moderate
CWE: CWE-703 (Improper Check or Handling of Exceptional Conditions)
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-10-21T00:00:00+00:00

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

x86/ioapic: Handle allocation failures gracefully

Breno observed panics when using failslab under certain conditions during
runtime:

   can not alloc irq_pin_list (-1,0,20)
   Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed

   panic+0x4e9/0x590
   mp_irqdomain_alloc+0x9ab/0xa80
   irq_domain_alloc_irqs_locked+0x25d/0x8d0
   __irq_domain_alloc_irqs+0x80/0x110
   mp_map_pin_to_irq+0x645/0x890
   acpi_register_gsi_ioapic+0xe6/0x150
   hpet_open+0x313/0x480

That's a pointless panic which is a leftover of the historic IO/APIC code
which panic'ed during early boot when the interrupt allocation failed.

The only place which might justify panic is the PIT/HPET timer_check() code
which tries to figure out whether the timer interrupt is delivered through
the IO/APIC. But that code does not require to handle interrupt allocation
failures. If the interrupt cannot be allocated then timer delivery fails
and it either panics due to that or falls back to legacy mode.

Cure this by removing the panic wrapper around __add_pin_to_irq_node() and
making mp_irqdomain_alloc() aware of the failure condition and handle it as
any other failure in this function gracefully.


Affected upstream versions: 4.2
Fixed upstream versions: 0, 5.15.168, 6.1.113, 6.10.14, 6.11.3, 6.12, 6.6.55
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: e479cb835feeb2abff97f25766e23b96a6eabe28
CVE-2024-49928: kernel: wifi: rtw89: avoid reading out of bounds when loading TX power FW elements
Component: kernel
Severity: Moderate
CWE: CWE-125 (Out-of-bounds Read)
CVSS v3: 7.1 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H)
Public date: 2024-10-21T00:00:00+00:00

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

wifi: rtw89: avoid reading out of bounds when loading TX power FW elements

Because the loop-expression will do one more time before getting false from
cond-expression, the original code copied one more entry size beyond valid
region.

Fix it by moving the entry copy to loop-body.


Affected upstream versions: 6.7
Fixed upstream versions: 0, 6.10.14, 6.11.3, 6.12
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 83c84cdb75572048b67d6a3916283aeac865996e
CVE-2024-49929: kernel: wifi: iwlwifi: mvm: avoid NULL pointer dereference
Component: kernel
Severity: Moderate
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-10-21T00:00:00+00:00

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

wifi: iwlwifi: mvm: avoid NULL pointer dereference

iwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvsta
pointer is not NULL.
It retrieves this pointer using iwl_mvm_sta_from_mac80211, which is
dereferencing the ieee80211_sta pointer.
If sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULL
pointer.
Fix this by checking the sta pointer before retrieving the mvmsta
from it. If sta is not NULL, then mvmsta isn't either.


Affected upstream versions: 3.14
Fixed upstream versions: 0, 6.1.120, 6.10.14, 6.11.3, 6.12, 6.6.55
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: cbc6fc9cfcde151ff5eadaefdc6155f99579384f
CVE-2024-49930: kernel: wifi: ath11k: fix array out-of-bound access in SoC stats
Component: kernel
Severity: Moderate
CVSS v3: 6.4 (CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H)
Public date: 2024-10-21T00:00:00+00:00

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

wifi: ath11k: fix array out-of-bound access in SoC stats

Currently, the ath11k_soc_dp_stats::hal_reo_error array is defined with a
maximum size of DP_REO_DST_RING_MAX. However, the ath11k_dp_process_rx()
function access ath11k_soc_dp_stats::hal_reo_error using the REO
destination SRNG ring ID, which is incorrect. SRNG ring ID differ from
normal ring ID, and this usage leads to out-of-bounds array access. To fix
this issue, modify ath11k_dp_process_rx() to use the normal ring ID
directly instead of the SRNG ring ID to avoid out-of-bounds array access.

Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1

Statement: The bug happens only on error path and requires preconditions to trigger it, so considering it Moderate.

Affected upstream versions: 5.6
Fixed upstream versions: 0, 5.10.227, 5.15.168, 6.1.113, 6.10.14, 6.11.3, 6.12, 6.6.55
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 0f26f26944035ec67546a944f182cbad6577a9c0
CVE-2024-49933: kernel: blk_iocost: fix more out of bound shifts
Component: kernel
Severity: Moderate
CWE: CWE-682 (Incorrect Calculation)
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-10-21T00:00:00+00:00

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

blk_iocost: fix more out of bound shifts

Recently running UBSAN caught few out of bound shifts in the
ioc_forgive_debts() function:

UBSAN: shift-out-of-bounds in block/blk-iocost.c:2142:38
shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long
long')
...
UBSAN: shift-out-of-bounds in block/blk-iocost.c:2144:30
shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long
long')
...
Call Trace:
<IRQ>
dump_stack_lvl+0xca/0x130
__ubsan_handle_shift_out_of_bounds+0x22c/0x280
? __lock_acquire+0x6441/0x7c10
ioc_timer_fn+0x6cec/0x7750
? blk_iocost_init+0x720/0x720
? call_timer_fn+0x5d/0x470
call_timer_fn+0xfa/0x470
? blk_iocost_init+0x720/0x720
__run_timer_base+0x519/0x700
...

Actual impact of this issue was not identified but I propose to fix the
undefined behaviour.
The proposed fix to prevent those out of bound shifts consist of
precalculating exponent before using it the shift operations by taking
min value from the actual exponent and maximum possible number of bits.


Affected upstream versions: 5.10
Fixed upstream versions: 0, 5.10.227, 5.15.168, 6.1.113, 6.10.14, 6.11.3, 6.12, 6.6.55
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 1f61d509257d6a05763d05bf37943b35306522b1
CVE-2024-49937: kernel: wifi: cfg80211: Set correct chandef when starting CAC
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-10-21T00:00:00+00:00

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

wifi: cfg80211: Set correct chandef when starting CAC

When starting CAC in a mode other than AP mode, it return a
"WARNING: CPU: 0 PID: 63 at cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]"
caused by the chandef.chan being null at the end of CAC.

Solution: Ensure the channel definition is set for the different modes
when starting CAC to avoid getting a NULL 'chan' at the end of CAC.

 Call Trace:
  ? show_regs.part.0+0x14/0x16
  ? __warn+0x67/0xc0
  ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]
  ? report_bug+0xa7/0x130
  ? exc_overflow+0x30/0x30
  ? handle_bug+0x27/0x50
  ? exc_invalid_op+0x18/0x60
  ? handle_exception+0xf6/0xf6
  ? exc_overflow+0x30/0x30
  ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]
  ? exc_overflow+0x30/0x30
  ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]
  ? regulatory_propagate_dfs_state.cold+0x1b/0x4c [cfg80211]
  ? cfg80211_propagate_cac_done_wk+0x1a/0x30 [cfg80211]
  ? process_one_work+0x165/0x280
  ? worker_thread+0x120/0x3f0
  ? kthread+0xc2/0xf0
  ? process_one_work+0x280/0x280
  ? kthread_complete_and_exit+0x20/0x20
  ? ret_from_fork+0x19/0x24

[shorten subject, remove OCB, reorder cases to match previous list]


Affected upstream versions: 5.19.2 < 5.20, 6.0
Fixed upstream versions: 0, 5.20, 6.1.113, 6.10.14, 6.11.3, 6.12, 6.6.55
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 95f32191e50b75e0f75fae1bb925cdf51d8df0a3
CVE-2024-49938: kernel: wifi: ath9k_htc: Use __skb_set_length() for resetting urb before resubmit
Component: kernel
Severity: Moderate
CWE: CWE-824 (Access of Uninitialized Pointer)
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-10-21T00:00:00+00:00

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

wifi: ath9k_htc: Use __skb_set_length() for resetting urb before resubmit

Syzbot points out that skb_trim() has a sanity check on the existing length of
the skb, which can be uninitialised in some error paths. The intent here is
clearly just to reset the length to zero before resubmitting, so switch to
calling __skb_set_length(skb, 0) directly. In addition, __skb_set_length()
already contains a call to skb_reset_tail_pointer(), so remove the redundant
call.

The syzbot report came from ath9k_hif_usb_reg_in_cb(), but there's a similar
usage of skb_trim() in ath9k_hif_usb_rx_cb(), change both while we're at it.


Affected upstream versions: 2.6.35
Fixed upstream versions: 0, 4.19.323, 5.10.227, 5.15.168, 5.4.285, 6.1.113, 6.10.14, 6.11.3, 6.12, 6.6.55
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: e6b9bf32e0695e4f374674002de0527d2a6768eb
CVE-2024-49948: kernel: net: add more sanity checks to qdisc_pkt_len_init()
Component: kernel
Severity: Moderate
CWE: CWE-20 (Improper Input Validation)
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-10-21T00:00:00+00:00

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

net: add more sanity checks to qdisc_pkt_len_init()

One path takes care of SKB_GSO_DODGY, assuming
skb->len is bigger than hdr_len.

virtio_net_hdr_to_skb() does not fully dissect TCP headers,
it only make sure it is at least 20 bytes.

It is possible for an user to provide a malicious 'GSO' packet,
total length of 80 bytes.

- 20 bytes of IPv4 header
- 60 bytes TCP header
- a small gso_size like 8

virtio_net_hdr_to_skb() would declare this packet as a normal
GSO packet, because it would see 40 bytes of payload,
bigger than gso_size.

We need to make detect this case to not underflow
qdisc_skb_cb(skb)->pkt_len.


Affected upstream versions: 3.9
Fixed upstream versions: 0, 4.19.323, 5.10.227, 5.15.168, 5.4.285, 6.1.113, 6.10.14, 6.11.3, 6.12, 6.6.55
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: d7d1a28f5dd57b4d83def876f8d7b4403bd37df9
CVE-2024-49951: kernel: Bluetooth: MGMT: Fix possible crash on mgmt_index_removed
Component: kernel
Severity: Moderate
CWE: CWE-416 (Use After Free)
CVSS v3: 4.7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-10-21T00:00:00+00:00

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

Bluetooth: MGMT: Fix possible crash on mgmt_index_removed

If mgmt_index_removed is called while there are commands queued on
cmd_sync it could lead to crashes like the bellow trace:

0x0000053D: __list_del_entry_valid_or_report+0x98/0xdc
0x0000053D: mgmt_pending_remove+0x18/0x58 [bluetooth]
0x0000053E: mgmt_remove_adv_monitor_complete+0x80/0x108 [bluetooth]
0x0000053E: hci_cmd_sync_work+0xbc/0x164 [bluetooth]

So while handling mgmt_index_removed this attempts to dequeue
commands passed as user_data to cmd_sync.

Statement: Bug could happen during removal of recourse by local user that limits impact.

Affected upstream versions: 6.0
Fixed upstream versions: 0, 6.1.120, 6.10.14, 6.11.3, 6.12, 6.6.55
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 19b40ca62607cef78369549d1af091f2fd558931
CVE-2024-49954: kernel: static_call: Replace pointless WARN_ON() in static_call_module_notify()
Component: kernel
Severity: Moderate
CWE: CWE-617 (Reachable Assertion)
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-10-21T00:00:00+00:00

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

static_call: Replace pointless WARN_ON() in static_call_module_notify()

static_call_module_notify() triggers a WARN_ON(), when memory allocation
fails in __static_call_add_module().

That's not really justified, because the failure case must be correctly
handled by the well known call chain and the error code is passed
through to the initiating userspace application.

A memory allocation fail is not a fatal problem, but the WARN_ON() takes
the machine out when panic_on_warn is set.

Replace it with a pr_warn().


Affected upstream versions: 5.10
Fixed upstream versions: 0, 5.15.168, 6.1.113, 6.10.14, 6.11.3, 6.12, 6.6.55
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: bc9356513d56b688775497b7ac6f2b967f46a80c
CVE-2024-49959: kernel: jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error
Component: kernel
Severity: Moderate
CWE: CWE-99 (Improper Control of Resource Identifiers ('Resource Injection'))
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-10-21T00:00:00+00:00

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

jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error

In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail()
to recover some journal space. But if an error occurs while executing
jbd2_cleanup_journal_tail() (e.g., an EIO), we don't stop waiting for free
space right away, we try other branches, and if j_committing_transaction
is NULL (i.e., the tid is 0), we will get the following complain:

============================================
JBD2: I/O error when updating journal superblock for sdd-8.
__jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available
__jbd2_log_wait_for_space: no way to get more journal space in sdd-8
------------[ cut here ]------------
WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0
Modules linked in:
CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1
RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0
Call Trace:
 <TASK>
 add_transaction_credits+0x5d1/0x5e0
 start_this_handle+0x1ef/0x6a0
 jbd2__journal_start+0x18b/0x340
 ext4_dirty_inode+0x5d/0xb0
 __mark_inode_dirty+0xe4/0x5d0
 generic_update_time+0x60/0x70
[...]
============================================

So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to
clean up at the moment, continue to try to reclaim free space in other ways.

Note that this fix relies on commit 6f6a6fda2945 ("jbd2: fix ocfs2 corrupt
when updating journal superblock fails") to make jbd2_cleanup_journal_tail
return the correct error code.


Affected upstream versions: 2.6.28
Fixed upstream versions: 0, 4.19.323, 5.10.227, 5.15.168, 5.4.285, 6.1.113, 6.10.14, 6.11.3, 6.12, 6.6.55
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 801a35dfef6996f3d5eaa96a59caf00440d9165e
CVE-2024-49960: kernel: ext4: fix timer use-after-free on failed mount
Component: kernel
Severity: Moderate
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-10-21T00:00:00+00:00

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

ext4: fix timer use-after-free on failed mount

Syzbot has found an ODEBUG bug in ext4_fill_super

The del_timer_sync function cancels the s_err_report timer,
which reminds about filesystem errors daily. We should
guarantee the timer is no longer active before kfree(sbi).

When filesystem mounting fails, the flow goes to failed_mount3,
where an error occurs when ext4_stop_mmpd is called, causing
a read I/O failure. This triggers the ext4_handle_error function
that ultimately re-arms the timer,
leaving the s_err_report timer active before kfree(sbi) is called.

Fix the issue by canceling the s_err_report timer after calling ext4_stop_mmpd.


Affected upstream versions: 5.10.51 < 5.10.237, 5.12.18 < 5.13, 5.13.3 < 5.14, 5.14
Fixed upstream versions: 0, 5.10.237, 5.13, 5.14, 5.15.181, 6.1.118, 6.10.14, 6.11.3, 6.12, 6.6.55
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 7aac0c17a8cdf4a3236991c1e60435c6a984076c
CVE-2024-49962: kernel: ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in acpi_db_convert_to_package()
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-10-21T00:00:00+00:00

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

ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in acpi_db_convert_to_package()

ACPICA commit 4d4547cf13cca820ff7e0f859ba83e1a610b9fd0

ACPI_ALLOCATE_ZEROED() may fail, elements might be NULL and will cause
NULL pointer dereference later.

[ rjw: Subject and changelog edits ]


Affected upstream versions: 4.4
Fixed upstream versions: 0, 4.19.323, 5.10.227, 5.15.168, 5.4.285, 6.1.113, 6.10.14, 6.11.3, 6.12, 6.6.55
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 4669da66ebc5b09881487f30669b0fcdb462188e
CVE-2024-49968: kernel: ext4: filesystems without casefold feature cannot be mounted with siphash
Component: kernel
Severity: Moderate
CWE: CWE-20 (Improper Input Validation)
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-10-21T00:00:00+00:00

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

ext4: filesystems without casefold feature cannot be mounted with siphash

When mounting the ext4 filesystem, if the default hash version is set to
DX_HASH_SIPHASH but the casefold feature is not set, exit the mounting.


Affected upstream versions: 5.13
Fixed upstream versions: 0, 5.15.198, 6.1.160, 6.11.3, 6.12, 6.6.120
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 86b81d4eab1cd4c56f7447896232cf33472c2395
CVE-2024-49971: kernel: drm/amd/display: Increase array size of dummy_boolean
Component: kernel
Severity: Moderate
CWE: CWE-119 (Improper Restriction of Operations within the Bounds of a Memory Buffer)
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-10-21T00:00:00+00:00

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

drm/amd/display: Increase array size of dummy_boolean

[WHY]
dml2_core_shared_mode_support and dml_core_mode_support access the third
element of dummy_boolean, i.e. hw_debug5 = &s->dummy_boolean[2], when
dummy_boolean has size of 2. Any assignment to hw_debug5 causes an
OVERRUN.

[HOW]
Increase dummy_boolean's array size to 3.

This fixes 2 OVERRUN issues reported by Coverity.


Affected upstream versions: 6.11
Fixed upstream versions: 0, 6.11.3, 6.12
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: e9e48b7bb9cf3b78f0305ef0144aaf61da0a83d8
CVE-2024-49973: kernel: r8169: add tally counter fields added with RTL8125
Component: kernel
Severity: Moderate
CWE: CWE-787 (Out-of-bounds Write)
CVSS v3: 4.1 (CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-10-21T00:00:00+00:00

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

r8169: add tally counter fields added with RTL8125

RTL8125 added fields to the tally counter, what may result in the chip
dma'ing these new fields to unallocated memory. Therefore make sure
that the allocated memory area is big enough to hold all of the
tally counter values, even if we use only parts of it.

Statement: The damage of memory could be by the hardware (the network card chip could damage it). It means that impact and possibilities for attack limited.

Affected upstream versions: 5.4
Fixed upstream versions: 0, 5.10.227, 5.15.168, 5.4.285, 6.1.113, 6.10.14, 6.11.3, 6.12, 6.6.55
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 64648ae8c97ec5a3165021627f5a1658ebe081ca
CVE-2024-49974: kernel: NFSD: Limit the number of concurrent async COPY operations
Component: kernel
Severity: Moderate
CWE: CWE-770 (Allocation of Resources Without Limits or Throttling)
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-10-21T00:00:00+00:00

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

NFSD: Limit the number of concurrent async COPY operations

Nothing appears to limit the number of concurrent async COPY
operations that clients can start. In addition, AFAICT each async
COPY can copy an unlimited number of 4MB chunks, so can run for a
long time. Thus IMO async COPY can become a DoS vector.

Add a restriction mechanism that bounds the number of concurrent
background COPY operations. Start simple and try to be fair -- this
patch implements a per-namespace limit.

An async COPY request that occurs while this limit is exceeded gets
NFS4ERR_DELAY. The requesting client can choose to send the request
again after a delay or fall back to a traditional read/write style
copy.

If there is need to make the mechanism more sophisticated, we can
visit that in future patches.


Affected upstream versions: 4.20
Fixed upstream versions: 0, 5.10.231, 5.15.174, 6.1.119, 6.10.14, 6.11.3, 6.12, 6.6.63
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 9e52ff544e0bfa09ee339fd7b0937ee3c080c24e
CVE-2024-49975: kernel: uprobes: fix kernel info leak via "[uprobes]" vma
Component: kernel
Severity: Moderate
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-10-21T00:00:00+00:00

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

uprobes: fix kernel info leak via "[uprobes]" vma

xol_add_vma() maps the uninitialized page allocated by __create_xol_area()
into userspace. On some architectures (x86) this memory is readable even
without VM_READ, VM_EXEC results in the same pgprot_t as VM_EXEC|VM_READ,
although this doesn't really matter, debugger can read this memory anyway.


Affected upstream versions: 3.5
Fixed upstream versions: 0, 4.19.323, 5.10.227, 5.15.168, 5.4.285, 6.1.113, 6.10.14, 6.11.3, 6.12, 6.6.55
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: f31f92107e5a8ecc8902705122c594e979a351fe
CVE-2024-49977: kernel: net: stmmac: Fix zero-division error when disabling tc cbs
Component: kernel
Severity: Low
CWE: CWE-369 (Divide By Zero)
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-10-21T00:00:00+00:00

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

net: stmmac: Fix zero-division error when disabling tc cbs

The commit b8c43360f6e4 ("net: stmmac: No need to calculate speed divider
when offload is disabled") allows the "port_transmit_rate_kbps" to be
set to a value of 0, which is then passed to the "div_s64" function when
tc-cbs is disabled. This leads to a zero-division error.

When tc-cbs is disabled, the idleslope, sendslope, and credit values the
credit values are not required to be configured. Therefore, adding a return
statement after setting the txQ mode to DCB when tc-cbs is disabled would
prevent a zero-division error.


Affected upstream versions: 5.10.221 < 5.10.227, 5.15.162 < 5.15.168, 6.1.96 < 6.1.113, 6.6.36 < 6.6.55, 6.9.7 < 6.10, 6.10
Fixed upstream versions: 0, 5.10.227, 5.15.168, 6.1.113, 6.10, 6.10.14, 6.11.3, 6.12, 6.6.55
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: e33fe25b1efe4f2e6a5858786dbc82ae4c44ed4c