huzaifas-sidhpurwala/security-commit huggingface dataset:
CVE-2024-50251: kernel: netfilter: nft_payload: sanitize offset and length before calling skb_checksum()
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-11-09T00:00:00+00:00

An incorrect buffer length flaw was found in the Linux kernel's netfilter subsystem. A local user could trigger the nft_payload_set_eval function and use this issue to crash the system.

Statement: The security impact is limited because this issue is handled by BUG_ON() and only privileged user can trigger it.

Affected upstream versions: 4.5
Fixed upstream versions: 0, 4.19.323, 5.10.229, 5.15.171, 5.4.285, 6.1.116, 6.11.7, 6.12, 6.6.60
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: a661ed364ae6ae88c2fafa9ddc27df1af2a73701
CVE-2024-50255: kernel: Bluetooth: hci: fix null-ptr-deref in hci_read_supported_codecs
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-11-09T00:00:00+00:00

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

Bluetooth: hci: fix null-ptr-deref in hci_read_supported_codecs

Fix __hci_cmd_sync_sk() to return not NULL for unknown opcodes.

__hci_cmd_sync_sk() returns NULL if a command returns a status event.
However, it also returns NULL where an opcode doesn't exist in the
hci_cc table because hci_cmd_complete_evt() assumes status = skb->data[0]
for unknown opcodes.
This leads to null-ptr-deref in cmd_sync for HCI_OP_READ_LOCAL_CODECS as
there is no hci_cc for HCI_OP_READ_LOCAL_CODECS, which always assumes
status = skb->data[0].

KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077]
CPU: 1 PID: 2000 Comm: kworker/u9:5 Not tainted 6.9.0-ga6bcb805883c-dirty #10
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Workqueue: hci7 hci_power_on
RIP: 0010:hci_read_supported_codecs+0xb9/0x870 net/bluetooth/hci_codec.c:138
Code: 08 48 89 ef e8 b8 c1 8f fd 48 8b 75 00 e9 96 00 00 00 49 89 c6 48 ba 00 00 00 00 00 fc ff df 4c 8d 60 70 4c 89 e3 48 c1 eb 03 <0f> b6 04 13 84 c0 0f 85 82 06 00 00 41 83 3c 24 02 77 0a e8 bf 78
RSP: 0018:ffff888120bafac8 EFLAGS: 00010212
RAX: 0000000000000000 RBX: 000000000000000e RCX: ffff8881173f0040
RDX: dffffc0000000000 RSI: ffffffffa58496c0 RDI: ffff88810b9ad1e4
RBP: ffff88810b9ac000 R08: ffffffffa77882a7 R09: 1ffffffff4ef1054
R10: dffffc0000000000 R11: fffffbfff4ef1055 R12: 0000000000000070
R13: 0000000000000000 R14: 0000000000000000 R15: ffff88810b9ac000
FS:  0000000000000000(0000) GS:ffff8881f6c00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f6ddaa3439e CR3: 0000000139764003 CR4: 0000000000770ef0
PKRU: 55555554
Call Trace:
 <TASK>
 hci_read_local_codecs_sync net/bluetooth/hci_sync.c:4546 [inline]
 hci_init_stage_sync net/bluetooth/hci_sync.c:3441 [inline]
 hci_init4_sync net/bluetooth/hci_sync.c:4706 [inline]
 hci_init_sync net/bluetooth/hci_sync.c:4742 [inline]
 hci_dev_init_sync net/bluetooth/hci_sync.c:4912 [inline]
 hci_dev_open_sync+0x19a9/0x2d30 net/bluetooth/hci_sync.c:4994
 hci_dev_do_open net/bluetooth/hci_core.c:483 [inline]
 hci_power_on+0x11e/0x560 net/bluetooth/hci_core.c:1015
 process_one_work kernel/workqueue.c:3267 [inline]
 process_scheduled_works+0x8ef/0x14f0 kernel/workqueue.c:3348
 worker_thread+0x91f/0xe50 kernel/workqueue.c:3429
 kthread+0x2cb/0x360 kernel/kthread.c:388
 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244


Affected upstream versions: 5.17
Fixed upstream versions: 0, 6.1.116, 6.11.7, 6.12, 6.6.60
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 5d9054b9f769a8e124c4fa02072437c864726baf
CVE-2024-50261: kernel: macsec: Fix use-after-free while sending the offloading packet
Component: kernel
Severity: Moderate
CWE: CWE-416 (Use After Free)
CVSS v3: 6.1 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:L)
Public date: 2024-11-09T00:00:00+00:00

A use-after-free vulnerability was found in the Linux kernel. The metadata_dst, which is used to store the SCI value for macsec offload, is freed by metadata_dst_free() in macsec_free_netdev(), while the driver still uses it to send the packet.


Affected upstream versions: 6.1
Fixed upstream versions: 0, 6.1.116, 6.11.7, 6.12, 6.6.60
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 872932cf75cf859804370a265dd58118129386fa
CVE-2024-50262: kernel: bpf: Fix out-of-bounds write in trie_get_next_key()
Component: kernel
Severity: Moderate
CWE: CWE-787 (Out-of-bounds Write)
CVSS v3: 6.7 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H)
Public date: 2024-11-09T00:00:00+00:00

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

bpf: Fix out-of-bounds write in trie_get_next_key()

trie_get_next_key() allocates a node stack with size trie->max_prefixlen,
while it writes (trie->max_prefixlen + 1) nodes to the stack when it has
full paths from the root to leaves. For example, consider a trie with
max_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ...
0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with
.prefixlen = 8 make 9 nodes be written on the node stack with size 8.

Statement: The default Red Hat Enterprise Linux kernel prevents unprivileged users from being able to use eBPF by the kernel.unprivileged_bpf_disabled sysctl. This would require a privileged user with CAP_SYS_ADMIN or root to be able to abuse this flaw reducing its attack space.

For the Red Hat Enterprise Linux 9 to confirm the current state, inspect the sysctl with the command:

    cat /proc/sys/kernel/unprivileged_bpf_disabled

The setting of 1 would mean that unprivileged users can not use eBPF, mitigating the flaw.

Affected upstream versions: 4.16
Fixed upstream versions: 0, 4.19.323, 5.10.229, 5.15.171, 5.4.285, 6.1.116, 6.11.7, 6.12, 6.6.60
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: e8494ac079814a53fbc2258d2743e720907488ed
CVE-2024-50264: kernel: vsock/virtio: Initialization of the dangling pointer occurring in vsk->trans
Component: kernel
Severity: Moderate
CWE: CWE-416 (Use After Free)
CVSS v3: 6 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:H)
Public date: 2024-11-19T00:00:00+00:00

A dangling pointer can be created in vsk->trans, potentially leading to a Use-After-Free condition.


Affected upstream versions: 4.8
Fixed upstream versions: 0, 4.19.324, 5.10.230, 5.15.172, 5.4.286, 6.1.117, 6.11.8, 6.12, 6.6.61
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 5f092a4271f6dccf88fe0d132475a17b69ef71df
CVE-2024-50271: kernel: signal: restore the override_rlimit logic
Component: kernel
Severity: Moderate
CWE: CWE-670 (Always-Incorrect Control Flow Implementation)
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-11-19T00:00:00+00:00

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

signal: restore the override_rlimit logic

Prior to commit d64696905554 ("Reimplement RLIMIT_SIGPENDING on top of
ucounts") UCOUNT_RLIMIT_SIGPENDING rlimit was not enforced for a class of
signals.  However now it's enforced unconditionally, even if
override_rlimit is set.  This behavior change caused production issues.  

For example, if the limit is reached and a process receives a SIGSEGV
signal, sigqueue_alloc fails to allocate the necessary resources for the
signal delivery, preventing the signal from being delivered with siginfo. 
This prevents the process from correctly identifying the fault address and
handling the error.  From the user-space perspective, applications are
unaware that the limit has been reached and that the siginfo is
effectively 'corrupted'.  This can lead to unpredictable behavior and
crashes, as we observed with java applications.

Fix this by passing override_rlimit into inc_rlimit_get_ucounts() and skip
the comparison to max there if override_rlimit is set.  This effectively
restores the old behavior.


Affected upstream versions: 5.14
Fixed upstream versions: 0, 6.1.117, 6.11.8, 6.12, 6.6.61
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 012f4d5d25e9ef92ee129bd5aa7aa60f692681e1
CVE-2024-50272: kernel: filemap: Fix bounds checking in filemap_read()
Component: kernel
Severity: Moderate
CWE: CWE-835 (Loop with Unreachable Exit Condition ('Infinite Loop'))
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-11-19T00:00:00+00:00

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

filemap: Fix bounds checking in filemap_read()

If the caller supplies an iocb->ki_pos value that is close to the
filesystem upper limit, and an iterator with a count that causes us to
overflow that limit, then filemap_read() enters an infinite loop.

This behaviour was discovered when testing xfstests generic/525 with the
"localio" optimisation for loopback NFS mounts.


Affected upstream versions: 3.16.40 < 3.17, 4.7.10 < 4.8, 4.8.4 < 4.9, 4.9
Fixed upstream versions: 0, 3.17, 4.8, 4.9, 5.15.181, 6.1.117, 6.11.8, 6.12, 6.6.61
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 6cc52df69e8464811f9f6fc12f7aaa78451eb0b8
CVE-2024-50275: kernel: arm64/sve: Discard stale CPU state when handling SVE traps
Component: kernel
Severity: Moderate
CWE: CWE-99 (Improper Control of Resource Identifiers ('Resource Injection'))
CVSS v3: 6.3 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:H)
Public date: 2024-11-19T00:00:00+00:00

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

arm64/sve: Discard stale CPU state when handling SVE traps

The logic for handling SVE traps manipulates saved FPSIMD/SVE state
incorrectly, and a race with preemption can result in a task having
TIF_SVE set and TIF_FOREIGN_FPSTATE clear even though the live CPU state
is stale (e.g. with SVE traps enabled). This has been observed to result
in warnings from do_sve_acc() where SVE traps are not expected while
TIF_SVE is set:

|         if (test_and_set_thread_flag(TIF_SVE))
|                 WARN_ON(1); /* SVE access shouldn't have trapped */

Warnings of this form have been reported intermittently, e.g.

  https://lore.kernel.org/linux-arm-kernel/CA+G9fYtEGe_DhY2Ms7+L7NKsLYUomGsgqpdBj+QwDLeSg=JhGg@mail.gmail.com/
  https://lore.kernel.org/linux-arm-kernel/000000000000511e9a060ce5a45c@google.com/

The race can occur when the SVE trap handler is preempted before and
after manipulating the saved FPSIMD/SVE state, starting and ending on
the same CPU, e.g.

| void do_sve_acc(unsigned long esr, struct pt_regs *regs)
| {
|         // Trap on CPU 0 with TIF_SVE clear, SVE traps enabled
|         // task->fpsimd_cpu is 0.
|         // per_cpu_ptr(&fpsimd_last_state, 0) is task.
|
|         ...
|
|         // Preempted; migrated from CPU 0 to CPU 1.
|         // TIF_FOREIGN_FPSTATE is set.
|
|         get_cpu_fpsimd_context();
|
|         if (test_and_set_thread_flag(TIF_SVE))
|                 WARN_ON(1); /* SVE access shouldn't have trapped */
|
|         sve_init_regs() {
|                 if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) {
|                         ...
|                 } else {
|                         fpsimd_to_sve(current);
|                         current->thread.fp_type = FP_STATE_SVE;
|                 }
|         }
|
|         put_cpu_fpsimd_context();
|
|         // Preempted; migrated from CPU 1 to CPU 0.
|         // task->fpsimd_cpu is still 0
|         // If per_cpu_ptr(&fpsimd_last_state, 0) is still task then:
|         // - Stale HW state is reused (with SVE traps enabled)
|         // - TIF_FOREIGN_FPSTATE is cleared
|         // - A return to userspace skips HW state restore
| }

Fix the case where the state is not live and TIF_FOREIGN_FPSTATE is set
by calling fpsimd_flush_task_state() to detach from the saved CPU
state. This ensures that a subsequent context switch will not reuse the
stale CPU state, and will instead set TIF_FOREIGN_FPSTATE, forcing the
new state to be reloaded from memory prior to a return to userspace.


Affected upstream versions: 5.13
Fixed upstream versions: 0, 5.15.174, 6.1.120, 6.11.8, 6.12, 6.6.61
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 51d3d80a6dc314982a9a0aeb0961085922a1aa15
CVE-2024-50278: kernel: dm cache: fix potential out-of-bounds access on the first resume
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-11-19T00:00:00+00:00

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

dm cache: fix potential out-of-bounds access on the first resume

Out-of-bounds access occurs if the fast device is expanded unexpectedly
before the first-time resume of the cache table. This happens because
expanding the fast device requires reloading the cache table for
cache_create to allocate new in-core data structures that fit the new
size, and the check in cache_preresume is not performed during the
first resume, leading to the issue.

Reproduce steps:

1. prepare component devices:

dmsetup create cmeta --table "0 8192 linear /dev/sdc 0"
dmsetup create cdata --table "0 65536 linear /dev/sdc 8192"
dmsetup create corig --table "0 524288 linear /dev/sdc 262144"
dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct

2. load a cache table of 512 cache blocks, and deliberately expand the
   fast device before resuming the cache, making the in-core data
   structures inadequate.

dmsetup create cache --notable
dmsetup reload cache --table "0 524288 cache /dev/mapper/cmeta \
/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"
dmsetup reload cdata --table "0 131072 linear /dev/sdc 8192"
dmsetup resume cdata
dmsetup resume cache

3. suspend the cache to write out the in-core dirty bitset and hint
   array, leading to out-of-bounds access to the dirty bitset at offset
   0x40:

dmsetup suspend cache

KASAN reports:

  BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80
  Read of size 8 at addr ffffc90000085040 by task dmsetup/90

  (...snip...)
  The buggy address belongs to the virtual mapping at
   [ffffc90000085000, ffffc90000087000) created by:
   cache_ctr+0x176a/0x35f0

  (...snip...)
  Memory state around the buggy address:
   ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
   ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
  >ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8
                                             ^
   ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
   ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8

Fix by checking the size change on the first resume.


Affected upstream versions: 3.13
Fixed upstream versions: 0, 4.19.324, 5.10.230, 5.15.172, 5.4.286, 6.1.117, 6.11.8, 6.12, 6.6.61
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: e492f71854ce03474d49e87fd98b8df1f7cd1d2d
CVE-2024-50282: kernel: drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read()
Component: kernel
Severity: Moderate
CWE: CWE-120 (Buffer Copy without Checking Size of Input ('Classic Buffer Overflow'))
CVSS v3: 6.7 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H)
Public date: 2024-11-19T00:00:00+00:00

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

drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read()

Avoid a possible buffer overflow if size is larger than 4K.

(cherry picked from commit f5d873f5825b40d886d03bd2aede91d4cf002434)

Statement: This issue is considered to be a moderate impact flaw, as the exploitation for this will need an ADMIN (or ROOT) privilege (PR:H).

Affected upstream versions: 4.2
Fixed upstream versions: 0, 4.19.324, 6.11.8, 6.12, 6.6.61
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 673bdb4200c092692f83b5f7ba3df57021d52d29
CVE-2024-50294: kernel: rxrpc: Fix missing locking causing hanging calls
Component: kernel
Severity: Moderate
CWE: CWE-413 (Improper Resource Locking)
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-11-19T00:00:00+00:00

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

rxrpc: Fix missing locking causing hanging calls

If a call gets aborted (e.g. because kafs saw a signal) between it being
queued for connection and the I/O thread picking up the call, the abort
will be prioritised over the connection and it will be removed from
local->new_client_calls by rxrpc_disconnect_client_call() without a lock
being held.  This may cause other calls on the list to disappear if a race
occurs.

Fix this by taking the client_call_lock when removing a call from whatever
list its ->wait_link happens to be on.


Affected upstream versions: 6.2
Fixed upstream versions: 0, 6.11.8, 6.12, 6.6.61
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 996a7208dadbf2cdda8d51444d5ee1fdd1ccbc92
CVE-2024-50299: kernel: sctp: properly validate chunk size in sctp_sf_ootb()
Component: kernel
Severity: Moderate
CWE: CWE-908 (Use of Uninitialized Resource)
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-11-19T00:00:00+00:00

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

sctp: properly validate chunk size in sctp_sf_ootb()

A size validation fix similar to that in Commit 50619dbf8db7 ("sctp: add
size validation when walking chunks") is also required in sctp_sf_ootb()
to address a crash reported by syzbot:

  BUG: KMSAN: uninit-value in sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712
  sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712
  sctp_do_sm+0x181/0x93d0 net/sctp/sm_sideeffect.c:1166
  sctp_endpoint_bh_rcv+0xc38/0xf90 net/sctp/endpointola.c:407
  sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88
  sctp_rcv+0x3831/0x3b20 net/sctp/input.c:243
  sctp4_rcv+0x42/0x50 net/sctp/protocol.c:1159
  ip_protocol_deliver_rcu+0xb51/0x13d0 net/ipv4/ip_input.c:205
  ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233


Affected upstream versions: 2.6.12
Fixed upstream versions: 0, 4.19.324, 5.10.230, 5.15.172, 5.4.286, 6.1.117, 6.11.8, 6.12, 6.6.61
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 67b9a278b80f71ec62091ded97c6bcbea33b5ec3
CVE-2024-50302: kernel: HID: core: zero-initialize the report buffer
Component: kernel
Severity: Moderate
CWE: CWE-908 (Use of Uninitialized Resource)
CVSS v3: 6.1 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:H)
Public date: 2024-11-19T00:00:00+00:00

A vulnerability was found in the Linux kernel's driver for Human Interface Devices. This flaw allows an attacker to use a malicious input device to read information from the report buffer. This could be used to leak kernel memory, enabling the exploitation of additional vulnerabilities.

Statement: While this vulnerability could lead to disclosure of kernel memory, the impact is rated Moderate because exploitation  requires bypassing additional security features such as kernel address-space layout randomization (KASLR). It could be exploited by an authenticated, local attacker who emulates a malicious Human Interface Device (HID).

Affected upstream versions: 3.10.16 < 3.11, 3.11.5 < 3.12, 3.12
Fixed upstream versions: 0, 3.11, 3.12, 4.19.324, 5.10.230, 5.15.172, 5.4.286, 6.1.117, 6.11.8, 6.12, 6.6.61
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: e7ea60184e1e88a3c9e437b3265cbb6439aa7e26
CVE-2024-50304: kernel: ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find()
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-11-19T00:00:00+00:00

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

ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find()

The per-netns IP tunnel hash table is protected by the RTNL mutex and
ip_tunnel_find() is only called from the control path where the mutex is
taken.

Add a lockdep expression to hlist_for_each_entry_rcu() in
ip_tunnel_find() in order to validate that the mutex is held and to
silence the suspicious RCU usage warning [1].

[1]
WARNING: suspicious RCU usage
6.12.0-rc3-custom-gd95d9a31aceb #139 Not tainted
-----------------------------
net/ipv4/ip_tunnel.c:221 RCU-list traversed in non-reader section!!

other info that might help us debug this:

rcu_scheduler_active = 2, debug_locks = 1
1 lock held by ip/362:
 #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60

stack backtrace:
CPU: 12 UID: 0 PID: 362 Comm: ip Not tainted 6.12.0-rc3-custom-gd95d9a31aceb #139
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
Call Trace:
 <TASK>
 dump_stack_lvl+0xba/0x110
 lockdep_rcu_suspicious.cold+0x4f/0xd6
 ip_tunnel_find+0x435/0x4d0
 ip_tunnel_newlink+0x517/0x7a0
 ipgre_newlink+0x14c/0x170
 __rtnl_newlink+0x1173/0x19c0
 rtnl_newlink+0x6c/0xa0
 rtnetlink_rcv_msg+0x3cc/0xf60
 netlink_rcv_skb+0x171/0x450
 netlink_unicast+0x539/0x7f0
 netlink_sendmsg+0x8c1/0xd80
 ____sys_sendmsg+0x8f9/0xc20
 ___sys_sendmsg+0x197/0x1e0
 __sys_sendmsg+0x122/0x1f0
 do_syscall_64+0xbb/0x1d0
 entry_SYSCALL_64_after_hwframe+0x77/0x7f


Affected upstream versions: 3.10
Fixed upstream versions: 0, 5.10.234, 5.15.178, 6.1.128, 6.11.7, 6.12, 6.6.75
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 31bd7378c6fe100a8af0e996ea0b5dafd3579df6
CVE-2024-50349: git: Git does not sanitize URLs when asking for credentials interactively
Component: git
Severity: Low
CWE: CWE-838 (Inappropriate Encoding for Output Context)
CVSS v3: 3.1 (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N)
Public date: 2025-01-14T18:43:42.620000+00:00

A flaw was found in Git. This vulnerability occurs when Git requests credentials via a terminal prompt, for example, without the use of a credential helper. During this process, Git displays the host name for which the credentials are needed, but any URL-encoded parts are decoded and displayed directly. This can allow an attacker to manipulate URLs by including ANSI escape sequences, which can be interpreted by the terminal to mislead users by tricking them into entering passwords that are redirected to malicious attacker-controlled sites.


Affected upstream versions: <= 2.40.3, >= 2.41.0, <= 2.41.2, >= 2.42.0, <= 2.42.3, >= 2.43.0, <= 2.43.5, >= 2.44.0, <= 2.44.2, >= 2.45.0, <= 2.45.2, >= 2.46.0, <= 2.46.2, >= 2.47.0, < 2.47.2, = 2.48.0
Fixed upstream versions: v2.40.4
Upstream repository: https://github.com/git/git
Upstream fix commit: 7725b8100ffbbff2750ee4d61a0fcc1f53a086e8
CVE-2024-51744: golang-jwt: Bad documentation of error handling in ParseWithClaims can lead to potentially dangerous situations in golang-jwt
Component: golang-jwt
Severity: Low
CWE: CWE-755 (Improper Handling of Exceptional Conditions)
CVSS v3: 3.1 (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N)
Public date: 2024-11-04T21:47:12.170000+00:00

A flaw was found in the golang-jwt package. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they can miss the embedded `jwt.ErrTokenSignatureInvalid`, and thus, potentially accept invalid tokens.


Affected upstream versions: < 4.5.1
Fixed upstream versions: v4.5.1
Upstream repository: https://github.com/golang-jwt/jwt
Upstream fix commit: 7b1c1c00a171c6c79bbdb40e4ce7d197060c1c2c