deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2024-43892
Published: 2024-08-26
Description: In the Linux kernel, the following vulnerability has been resolved:

memcg: protect concurrent access to mem_cgroup_idr

Commit 73f576c04b94 ("mm: memcontrol: fix cgroup creation failure after
many small jobs") decoupled the memcg IDs from the CSS ID space to fix the
cgroup creation failures.  It introduced IDR to maintain the memcg ID
space.  The IDR depends on external synchronization mechanisms for
modifications.  For the mem_cgroup_idr, the idr_alloc() and idr_replace()
happen within css callback and thus are protected through cgroup_mutex
from concurrent modifications.  However idr_remove() for mem_cgroup_idr
was not protected against concurrency and can be run concurrently for
different memcgs when they hit their refcnt to zero.  Fix that.

We have been seeing list_lru based kernel crashes at a low frequency in
our fleet for a long time.  These crashes were in different part of
list_lru code including list_lru_add(), list_lru_del() and reparenting
code.  Upon further inspection, it looked like for a given object (dentry
and inode), the super_block's list_lru didn't have list_lru_one for the
memcg of that object.  The initial suspicions were either the object is
not allocated through kmem_cache_alloc_lru() or somehow
memcg_list_lru_alloc() failed to allocate list_lru_one() for a memcg but
returned success.  No evidence were found for these cases.

Looking more deeply, we started seeing situations where valid memcg's id
is not present in mem_cgroup_idr and in some cases multiple valid memcgs
have same id and mem_cgroup_idr is pointing to one of them.  So, the most
reasonable explanation is that these situations can happen due to race
between multiple idr_remove() calls or race between
idr_alloc()/idr_replace() and idr_remove().  These races are causing
multiple memcgs to acquire the same ID and then offlining of one of them
would cleanup list_lrus on the system for all of them.  Later access from
other memcgs to the list_lru cause crashes due to missing list_lru_one.
CVSS Score: 4.7 (MEDIUM)
References: https://git.kernel.org/stable/c/37a060b64ae83b76600d187d76591ce488ab836b; https://git.kernel.org/stable/c/51c0b1bb7541f8893ec1accba59eb04361a70946; https://git.kernel.org/stable/c/56fd70f4aa8b82199dbe7e99366b1fd7a04d86fb
CVE: CVE-2024-43893
Published: 2024-08-26
Description: In the Linux kernel, the following vulnerability has been resolved:

serial: core: check uartclk for zero to avoid divide by zero

Calling ioctl TIOCSSERIAL with an invalid baud_base can
result in uartclk being zero, which will result in a
divide by zero error in uart_get_divisor(). The check for
uartclk being zero in uart_set_info() needs to be done
before other settings are made as subsequent calls to
ioctl TIOCSSERIAL for the same port would be impacted if
the uartclk check was done where uartclk gets set.

Oops: divide error: 0000  PREEMPT SMP KASAN PTI
RIP: 0010:uart_get_divisor (drivers/tty/serial/serial_core.c:580)
Call Trace:
 <TASK>
serial8250_get_divisor (drivers/tty/serial/8250/8250_port.c:2576
    drivers/tty/serial/8250/8250_port.c:2589)
serial8250_do_set_termios (drivers/tty/serial/8250/8250_port.c:502
    drivers/tty/serial/8250/8250_port.c:2741)
serial8250_set_termios (drivers/tty/serial/8250/8250_port.c:2862)
uart_change_line_settings (./include/linux/spinlock.h:376
    ./include/linux/serial_core.h:608 drivers/tty/serial/serial_core.c:222)
uart_port_startup (drivers/tty/serial/serial_core.c:342)
uart_startup (drivers/tty/serial/serial_core.c:368)
uart_set_info (drivers/tty/serial/serial_core.c:1034)
uart_set_info_user (drivers/tty/serial/serial_core.c:1059)
tty_set_serial (drivers/tty/tty_io.c:2637)
tty_ioctl (drivers/tty/tty_io.c:2647 drivers/tty/tty_io.c:2791)
__x64_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:907
    fs/ioctl.c:893 fs/ioctl.c:893)
do_syscall_64 (arch/x86/entry/common.c:52
    (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1))
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)

Rule: add
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-369
References: https://git.kernel.org/stable/c/3bbd90fca824e6fd61fb20f6dd2b0fa5f8b14bba; https://git.kernel.org/stable/c/52b138f1021113e593ee6ad258ce08fe90693a9e; https://git.kernel.org/stable/c/55b2a5d331a6ceb1c4372945fdb77181265ba24f
CVE: CVE-2024-43894
Published: 2024-08-26
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/client: fix null pointer dereference in drm_client_modeset_probe

In drm_client_modeset_probe(), the return value of drm_mode_duplicate() is
assigned to modeset->mode, which will lead to a possible NULL pointer
dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/113fd6372a5bb3689aba8ef5b8a265ed1529a78f; https://git.kernel.org/stable/c/24ddda932c43ffe156c7f3c568bed85131c63ae6; https://git.kernel.org/stable/c/5291d4f73452c91e8a11f71207617e3e234d418e
CVE: CVE-2024-43895
Published: 2024-08-26
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-43896
Published: 2024-08-26
Description: In the Linux kernel, the following vulnerability has been resolved:

ASoC: cs-amp-lib: Fix NULL pointer crash if efi.get_variable is NULL

Call efi_rt_services_supported() to check that efi.get_variable exists
before calling it.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/5b6baaa7cbd77ff980516bad38bbc5a648bb5158; https://git.kernel.org/stable/c/dc268085e499666b9f4f0fcb4c5a94e1c0b193b3
CVE: CVE-2024-43897
Published: 2024-08-26
Description: In the Linux kernel, the following vulnerability has been resolved:

net: drop bad gso csum_start and offset in virtio_net_hdr

Tighten csum_start and csum_offset checks in virtio_net_hdr_to_skb
for GSO packets.

The function already checks that a checksum requested with
VIRTIO_NET_HDR_F_NEEDS_CSUM is in skb linear. But for GSO packets
this might not hold for segs after segmentation.

Syzkaller demonstrated to reach this warning in skb_checksum_help

	offset = skb_checksum_start_offset(skb);
	ret = -EINVAL;
	if (WARN_ON_ONCE(offset >= skb_headlen(skb)))

By injecting a TSO packet:

WARNING: CPU: 1 PID: 3539 at net/core/dev.c:3284 skb_checksum_help+0x3d0/0x5b0
 ip_do_fragment+0x209/0x1b20 net/ipv4/ip_output.c:774
 ip_finish_output_gso net/ipv4/ip_output.c:279 [inline]
 __ip_finish_output+0x2bd/0x4b0 net/ipv4/ip_output.c:301
 iptunnel_xmit+0x50c/0x930 net/ipv4/ip_tunnel_core.c:82
 ip_tunnel_xmit+0x2296/0x2c70 net/ipv4/ip_tunnel.c:813
 __gre_xmit net/ipv4/ip_gre.c:469 [inline]
 ipgre_xmit+0x759/0xa60 net/ipv4/ip_gre.c:661
 __netdev_start_xmit include/linux/netdevice.h:4850 [inline]
 netdev_start_xmit include/linux/netdevice.h:4864 [inline]
 xmit_one net/core/dev.c:3595 [inline]
 dev_hard_start_xmit+0x261/0x8c0 net/core/dev.c:3611
 __dev_queue_xmit+0x1b97/0x3c90 net/core/dev.c:4261
 packet_snd net/packet/af_packet.c:3073 [inline]

The geometry of the bad input packet at tcp_gso_segment:

[   52.003050][ T8403] skb len=12202 headroom=244 headlen=12093 tailroom=0
[   52.003050][ T8403] mac=(168,24) mac_len=24 net=(192,52) trans=244
[   52.003050][ T8403] shinfo(txflags=0 nr_frags=1 gso(size=1552 type=3 segs=0))
[   52.003050][ T8403] csum(0x60000c7 start=199 offset=1536
ip_summed=3 complete_sw=0 valid=0 level=0)

Mitigate with stricter input validation.

csum_offset: for GSO packets, deduce the correct value from gso_type.
This is already done for USO. Extend it to TSO. Let UFO be:
udp[46]_ufo_fragment ignores these fields and always computes the
checksum in software.

csum_start: finding the real offset requires parsing to the transport
header. Do not add a parser, use existing segmentation parsing. Thanks
to SKB_GSO_DODGY, that also catches bad packets that are hw offloaded.
Again test both TSO and USO. Do not test UFO for the above reason, and
do not test UDP tunnel offload.

GSO packet are almost always CHECKSUM_PARTIAL. USO packets may be
CHECKSUM_NONE since commit 10154dbded6d6 ("udp: Allow GSO transmit
from devices with no checksum offload"), but then still these fields
are initialized correctly in udp4_hwcsum/udp6_hwcsum_outgoing. So no
need to test for ip_summed == CHECKSUM_PARTIAL first.

This revises an existing fix mentioned in the Fixes tag, which broke
small packets with GSO offload, as detected by kselftests.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2edbb3e8838c672cd7e247e47989df9d03fc6668; https://git.kernel.org/stable/c/413e785a89f8bde0d4156a54b8ac2fa003c06756; https://git.kernel.org/stable/c/6772c4868a8e7ad5305957cdb834ce881793acb7
CVE: CVE-2024-43898
Published: 2024-08-26
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-43899
Published: 2024-08-26
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Fix null pointer deref in dcn20_resource.c

Fixes a hang thats triggered when MPV is run on a DCN401 dGPU:

mpv --hwdec=vaapi --vo=gpu --hwdec-codecs=all

and then enabling fullscreen playback (double click on the video)

The following calltrace will be seen:

[  181.843989] BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
[  181.843997] #PF: supervisor instruction fetch in kernel mode
[  181.844003] #PF: error_code(0x0010) - not-present page
[  181.844009] PGD 0 P4D 0
[  181.844020] Oops: 0010 [#1] PREEMPT SMP NOPTI
[  181.844028] CPU: 6 PID: 1892 Comm: gnome-shell Tainted: G        W  OE      6.5.0-41-generic #41~22.04.2-Ubuntu
[  181.844038] Hardware name: System manufacturer System Product Name/CROSSHAIR VI HERO, BIOS 6302 10/23/2018
[  181.844044] RIP: 0010:0x0
[  181.844079] Code: Unable to access opcode bytes at 0xffffffffffffffd6.
[  181.844084] RSP: 0018:ffffb593c2b8f7b0 EFLAGS: 00010246
[  181.844093] RAX: [PII_REDACTED] RBX: [PII_REDACTED] RCX: [PII_REDACTED]
[  181.844099] RDX: ffffb593c2b8f804 RSI: ffffb593c2b8f7e0 RDI: ffff9e3c8e758400
[  181.844105] RBP: ffffb593c2b8f7b8 R08: ffffb593c2b8f9c8 R09: ffffb593c2b8f96c
[  181.844110] R10: [PII_REDACTED] R11: [PII_REDACTED] R12: ffffb593c2b8f9c8
[  181.844115] R13: [PII_REDACTED] R14: ffff9e3c88000000 R15: [PII_REDACTED]
[  181.844121] FS:  00007c6e323bb5c0(0000) GS:ffff9e3f85f80000(0000) knlGS:[PII_REDACTED]
[  181.844128] CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
[  181.844134] CR2: ffffffffffffffd6 CR3:[PII_REDACTED]fbe000 CR4:[PII_REDACTED]3506e0
[  181.844141] Call Trace:
[  181.844146]  <TASK>
[  181.844153]  ? show_regs+0x6d/0x80
[  181.844167]  ? __die+0x24/0x80
[  181.844179]  ? page_fault_oops+0x99/0x1b0
[  181.844192]  ? do_user_addr_fault+0x31d/0x6b0
[  181.844204]  ? exc_page_fault+0x83/0x1b0
[  181.844216]  ? asm_exc_page_fault+0x27/0x30
[  181.844237]  dcn20_get_dcc_compression_cap+0x23/0x30 [amdgpu]
[  181.845115]  amdgpu_dm_plane_validate_dcc.constprop.0+0xe5/0x180 [amdgpu]
[  181.845985]  amdgpu_dm_plane_fill_plane_buffer_attributes+0x300/0x580 [amdgpu]
[  181.846848]  fill_dc_plane_info_and_addr+0x258/0x350 [amdgpu]
[  181.847734]  fill_dc_plane_attributes+0x162/0x350 [amdgpu]
[  181.848748]  dm_update_plane_state.constprop.0+0x4e3/0x6b0 [amdgpu]
[  181.849791]  ? dm_update_plane_state.constprop.0+0x4e3/0x6b0 [amdgpu]
[  181.850840]  amdgpu_dm_atomic_check+0xdfe/0x1760 [amdgpu]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/6940c1d0c84a34d5a2038714c218238101a1db5b; https://git.kernel.org/stable/c/974fccd61758599a9716c4b909d9226749efe37e; https://git.kernel.org/stable/c/ecbf60782662f0a388493685b85a645a0ba1613c
CVE: CVE-2024-43901
Published: 2024-08-26
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Fix NULL pointer dereference for DTN log in DCN401

When users run the command:

cat /sys/kernel/debug/dri/0/amdgpu_dm_dtn_log

The following NULL pointer dereference happens:

[  +0.000003] BUG: kernel NULL pointer dereference, address: NULL
[  +0.000005] #PF: supervisor instruction fetch in kernel mode
[  +0.000002] #PF: error_code(0x0010) - not-present page
[  +0.000002] PGD 0 P4D 0
[  +0.000004] Oops: 0010 [#1] PREEMPT SMP NOPTI
[  +0.000003] RIP: 0010:0x0
[  +0.000008] Code: Unable to access opcode bytes at 0xffffffffffffffd6.
[...]
[  +0.000002] PKRU: 55555554
[  +0.000002] Call Trace:
[  +0.000002]  <TASK>
[  +0.000003]  ? show_regs+0x65/0x70
[  +0.000006]  ? __die+0x24/0x70
[  +0.000004]  ? page_fault_oops+0x160/0x470
[  +0.000006]  ? do_user_addr_fault+0x2b5/0x690
[  +0.000003]  ? prb_read_valid+0x1c/0x30
[  +0.000005]  ? exc_page_fault+0x8c/0x1a0
[  +0.000005]  ? asm_exc_page_fault+0x27/0x30
[  +0.000012]  dcn10_log_color_state+0xf9/0x510 [amdgpu]
[  +0.000306]  ? srso_alias_return_thunk+0x5/0xfbef5
[  +0.000003]  ? vsnprintf+0x2fb/0x600
[  +0.000009]  dcn10_log_hw_state+0xfd0/0xfe0 [amdgpu]
[  +0.000218]  ? __mod_memcg_lruvec_state+0xe8/0x170
[  +0.000008]  ? srso_alias_return_thunk+0x5/0xfbef5
[  +0.000002]  ? debug_smp_processor_id+0x17/0x20
[  +0.000003]  ? srso_alias_return_thunk+0x5/0xfbef5
[  +0.000002]  ? srso_alias_return_thunk+0x5/0xfbef5
[  +0.000002]  ? set_ptes.isra.0+0x2b/0x90
[  +0.000004]  ? srso_alias_return_thunk+0x5/0xfbef5
[  +0.000002]  ? _raw_spin_unlock+0x19/0x40
[  +0.000004]  ? srso_alias_return_thunk+0x5/0xfbef5
[  +0.000002]  ? do_anonymous_page+0x337/0x700
[  +0.000004]  dtn_log_read+0x82/0x120 [amdgpu]
[  +0.000207]  full_proxy_read+0x66/0x90
[  +0.000007]  vfs_read+0xb0/0x340
[  +0.000005]  ? __count_memcg_events+0x79/0xe0
[  +0.000002]  ? srso_alias_return_thunk+0x5/0xfbef5
[  +0.000003]  ? count_memcg_events.constprop.0+0x1e/0x40
[  +0.000003]  ? handle_mm_fault+0xb2/0x370
[  +0.000003]  ksys_read+0x6b/0xf0
[  +0.000004]  __x64_sys_read+0x19/0x20
[  +0.000003]  do_syscall_64+0x60/0x130
[  +0.000004]  entry_SYSCALL_64_after_hwframe+0x6e/0x76
[  +0.000003] RIP: 0033:0x7fdf32f147e2
[...]

This error happens when the color log tries to read the gamut remap
information from DCN401 which is not initialized in the dcn401_dpp_funcs
which leads to a null pointer dereference. This commit addresses this
issue by adding a proper guard to access the gamut_remap callback in
case the specific ASIC did not implement this function.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/1e68b7ce6bc6073579fe8713ec6b85aa9cd2e351; https://git.kernel.org/stable/c/5af[PII_REDACTED]17f8eb1bd0c80ad60fab519586b
CVE: CVE-2024-43902
Published: 2024-08-26
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Add null checker before passing variables

Checks null pointer before passing variables to functions.

This fixes 3 NULL_RETURNS issues reported by Coverity.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/[PII_REDACTED]d07f35eae7ff3d13a530034b899df2; https://git.kernel.org/stable/c/4cc2a94d96caeb3c975acdae7351c2f997c32175; https://git.kernel.org/stable/c/8092aa3ab8f7b737a34b71f91492c676a843043a
CVE: CVE-2024-43903
Published: 2024-08-26
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-43904
Published: 2024-08-26
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Add null checks for 'stream' and 'plane' before dereferencing

This commit adds null checks for the 'stream' and 'plane' variables in
the dcn30_apply_idle_power_optimizations function. These variables were
previously assumed to be null at line 922, but they were used later in
the code without checking if they were null. This could potentially lead
to a null pointer dereference, which would cause a crash.

The null checks ensure that 'stream' and 'plane' are not null before
they are used, preventing potential crashes.

Fixes the below static smatch checker:
drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:938 dcn30_apply_idle_power_optimizations() error: we previously assumed 'stream' could be null (see line 922)
drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:940 dcn30_apply_idle_power_optimizations() error: we previously assumed 'plane' could be null (see line 922)
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/10c20d79d59cadfe572480d98cec271a89ffb024; https://git.kernel.org/stable/c/15c2990e0f0108b9c3752d7072a97d45d4283aea; https://git.kernel.org/stable/c/16a8a2a839d19c4cf7253642b493ffb8eee1d857
CVE: CVE-2024-43905
Published: 2024-08-26
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/pm: Fix the null pointer dereference for vega10_hwmgr

Check return value and conduct null pointer handling to avoid null pointer dereference.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0fa11f9df96217c2785b040629ff1a16900fb51c; https://git.kernel.org/stable/c/2ac9deb7e087f0b461c3559d9eaa6b9cf19d3fa8; https://git.kernel.org/stable/c/2e538944996d0dd497faf8ee81f8bfcd3aca7d80
CVE: CVE-2024-43906
Published: 2024-08-26
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/admgpu: fix dereferencing null pointer context

When user space sets an invalid ta type, the pointer context will be empty.
So it need to check the pointer context before using it
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/030ffd4d43b433bc6671d9ec34fc12c59220b95d; https://git.kernel.org/stable/c/4fd52f7c2c11d330571c6bde06e5ea508ec25c9d; https://git.kernel.org/stable/c/641dac64178ccdb9e45c92b[PII_REDACTED]6294d05
CVE: CVE-2024-43907
Published: 2024-08-26
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu/pm: Fix the null pointer dereference in apply_state_adjust_rules

Check the pointer value to fix potential null pointer
dereference
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0c065e50445aea2e0a1815f12e97ee49e02cbaac; https://git.kernel.org/stable/c/13937a40aae4efe64592ba48c057ac3c72f7fe82; https://git.kernel.org/stable/c/3a01bf2ca9f860fdc88c358567b8fa3033efcf30
CVE: CVE-2024-43908
Published: 2024-08-26
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: Fix the null pointer dereference to ras_manager

Check ras_manager before using it
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/033187a70ba9743c73a810a006816e5553d1e7d4; https://git.kernel.org/stable/c/48cada0ac79e4775236d642e9ec5998a7c7fb7a4; https://git.kernel.org/stable/c/4c11d30c95576937c6c35e6f29884761f2dddb43
CVE: CVE-2024-43909
Published: 2024-08-26
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu/pm: Fix the null pointer dereference for smu7

optimize the code to avoid pass a null pointer (hwmgr->backend)
to function smu7_update_edc_leakage_table.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/09544cd95c688d3041328a4253bd[PII_REDACTED]bb; https://git.kernel.org/stable/c/1b8aa82b80bd947b68a8ab051d960a0c7935e22d; https://git.kernel.org/stable/c/37b9df457cbcf095963d18f17d6cb7dfa0a03fce
CVE: CVE-2024-43912
Published: 2024-08-26
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: nl80211: disallow setting special AP channel widths

Setting the AP channel width is meant for use with the normal
20/40/... MHz channel width progression, and switching around
in S1G or narrow channels isn't supported. Disallow that.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/23daf1b4c91db9b26f8425cc7039cf96d22ccbfe; https://git.kernel.org/stable/c/3d42f2125f6c89e1e71c87b9f23412afddbba45e; https://git.kernel.org/stable/c/ac3bf6e47fd8da9bfe8027e1acfe0282a91584fc
CVE: CVE-2024-43913
Published: 2024-08-26
Description: In the Linux kernel, the following vulnerability has been resolved:

nvme: apple: fix device reference counting

Drivers must call nvme_uninit_ctrl after a successful nvme_init_ctrl.
Split the allocation side out to make the error handling boundary easier
to navigate. The apple driver had been doing this wrong, leaking the
controller device memory on a tagset failure.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/b9ecbfa45516182cd062fecd286db7907ba84210; https://git.kernel.org/stable/c/d59c4d0eb6adc24c2201f153ccb7fd0a335b0d3d; https://git.kernel.org/stable/c/f7d9a18572fcd7130459b7691bd19ee2a2e951ad
CVE: CVE-2024-43914
Published: 2024-08-26
Description: In the Linux kernel, the following vulnerability has been resolved:

md/raid5: avoid BUG_ON() while continue reshape after reassembling

Currently, mdadm support --revert-reshape to abort the reshape while
reassembling, as the test 07revert-grow. However, following BUG_ON()
can be triggerred by the test:

kernel BUG at drivers/md/raid5.c:6278!
invalid opcode: 0000 [#1] PREEMPT SMP PTI
irq event stamp: 158985
CPU: 6 PID: 891 Comm: md0_reshape Not tainted 6.9.0-03335-g7592a0b0049a #94
RIP: 0010:reshape_request+0x3f1/0xe60
Call Trace:
 <TASK>
 raid5_sync_request+0x43d/0x550
 md_do_sync+0xb7a/0x2110
 md_thread+0x294/0x2b0
 kthread+0x147/0x1c0
 ret_from_fork+0x59/0x70
 ret_from_fork_asm+0x1a/0x30
 </TASK>

Root cause is that --revert-reshape update the raid_disks from 5 to 4,
while reshape position is still set, and after reassembling the array,
reshape position will be read from super block, then during reshape the
checking of 'writepos' that is caculated by old reshape position will
fail.

Fix this panic the easy way first, by converting the BUG_ON() to
WARN_ON(), and stop the reshape if checkings fail.

Noted that mdadm must fix --revert-shape as well, and probably md/raid
should enhance metadata validation as well, however this means
reassemble will fail and there must be user tools to fix the wrong
metadata.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2c92f8c1c456d556f15cbf51667b385026b2e6a0; https://git.kernel.org/stable/c/305a5170dc5cf3d395bb4c4e9239bca6d0b54b49; https://git.kernel.org/stable/c/3b33740c1750a39e046339ff9240e954f0156707
CVE: CVE-2024-44931
Published: 2024-08-26
Description: In the Linux kernel, the following vulnerability has been resolved:

gpio: prevent potential speculation leaks in gpio_device_get_desc()

Userspace may trigger a speculative read of an address outside the gpio
descriptor array.
Users can do that by calling gpio_ioctl() with an offset out of range.
Offset is copied from user and then used as an array index to get
the gpio descriptor without sanitization in gpio_device_get_desc().

This change ensures that the offset is sanitized by using
array_index_nospec() to mitigate any possibility of speculative
information leaks.

This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/[PII_REDACTED]671b02d00e6db9804a0ad26c5a479; https://git.kernel.org/stable/c/1b955f786a4bcde8c0ccb2b7d519def2acb6f3cc; https://git.kernel.org/stable/c/672c19165fc96dfad531a5458e0b3cdab414aae4