deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2024-26975
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

powercap: intel_rapl: Fix a NULL pointer dereference

A NULL pointer dereference is triggered when probing the MMIO RAPL
driver on platforms with CPU ID not listed in intel_rapl_common CPU
model list.

This is because the intel_rapl_common module still probes on such
platforms even if 'defaults_msr' is not set after commit 1488ac990ac8
("powercap: intel_rapl: Allow probing without CPUID match"). Thus the
MMIO RAPL rp->priv->defaults is NULL when registering to RAPL framework.

Fix the problem by adding sanity check to ensure rp->priv->rapl_defaults
is always valid.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0641908b906a133f1494c312a71f9fecbe2b6c78; https://git.kernel.org/stable/c/2d1f5006ff95770da502f8cee2a224a1ff83866e; https://git.kernel.org/stable/c/2f73cf2ae5e0f4e629db5be3a4380ff7807148e6
CVE: CVE-2024-26977
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

pci_iounmap(): Fix MMIO mapping leak

The #ifdef ARCH_HAS_GENERIC_IOPORT_MAP accidentally also guards iounmap(),
which means MMIO mappings are leaked.

Move the guard so we call iounmap() for MMIO mappings.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/5e4b23e7a7b33a1e56bfa3e5598138a2234d55b6; https://git.kernel.org/stable/c/6d21d0356aa44157a62e39c0d1a13d4c69a8d0c8; https://git.kernel.org/stable/c/[PII_REDACTED]cc786c238e2dd7d8740b17d41b2637
CVE: CVE-2024-26978
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

serial: max310x: fix NULL pointer dereference in I2C instantiation

When trying to instantiate a max14830 device from userspace:

    echo max14830 0x60 > /sys/bus/i2c/devices/i2c-2/new_device

we get the following error:

    Unable to handle kernel NULL pointer dereference at virtual address...
    ...
    Call trace:
        max310x_i2c_probe+0x48/0x170 [max310x]
        i2c_device_probe+0x150/0x2a0
    ...

Add check for validity of devtype to prevent the error, and abort probe
with a meaningful error message.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/0d27056c24efd3d63a03f3edfbcfc4827086b110; https://git.kernel.org/stable/c/12609c76b755dbeb1645c0aacc0f0f4743b2eff3; https://git.kernel.org/stable/c/2160ad6861c4a21d3fa553d7b2aaec6634a37f8a
CVE: CVE-2024-26979
Published: 2024-05-01
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-26980
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

ksmbd: fix slab-out-of-bounds in smb2_allocate_rsp_buf

If ->ProtocolId is SMB2_TRANSFORM_PROTO_NUM, smb2 request size
validation could be skipped. if request size is smaller than
sizeof(struct smb2_query_info_req), slab-out-of-bounds read can happen in
smb2_allocate_rsp_buf(). This patch allocate response buffer after
decrypting transform request. smb3_decrypt_req() will validate transform
request size and avoid slab-out-of-bound in smb2_allocate_rsp_buf().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-125
References: https://git.kernel.org/stable/c/0977f89722eceba165700ea384f075143f012085; https://git.kernel.org/stable/c/3160d9734453a40db248487f[PII_REDACTED]c207f1; https://git.kernel.org/stable/c/b80ba648714e6d790d69610cf14656be222d0248
CVE: CVE-2024-26981
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

nilfs2: fix OOB in nilfs_set_de_type

The size of the nilfs_type_by_mode array in the fs/nilfs2/dir.c file is
defined as "S_IFMT >> S_SHIFT", but the nilfs_set_de_type() function,
which uses this array, specifies the index to read from the array in the
same way as "(mode & S_IFMT) >> S_SHIFT".

static void nilfs_set_de_type(struct nilfs_dir_entry *de, struct inode
 *inode)
{
	umode_t mode = inode->i_mode;

	de->file_type = nilfs_type_by_mode[(mode & S_IFMT)>>S_SHIFT]; // oob
}

However, when the index is determined this way, an out-of-bounds (OOB)
error occurs by referring to an index that is 1 larger than the array size
when the condition "mode & S_IFMT == S_IFMT" is satisfied.  Therefore, a
patch to resize the nilfs_type_by_mode array should be applied to prevent
OOB errors.
CVSS Score: 7.8 (HIGH)
CWE: CWE-129
References: https://git.kernel.org/stable/c/054f29e9ca05be3906544c5f2a2c7321c30a4243; https://git.kernel.org/stable/c/2382eae66b196c31893984a538908c3eb7506ff9; https://git.kernel.org/stable/c/7061c7efbb9e8f11ce92d6b4646405ea2b0b4de1
CVE: CVE-2024-26982
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

Squashfs: check the inode number is not the invalid value of zero

Syskiller has produced an out of bounds access in fill_meta_index().

That out of bounds access is ultimately caused because the inode
has an inode number with the invalid value of zero, which was not checked.

The reason this causes the out of bounds access is due to following
sequence of events:

1. Fill_meta_index() is called to allocate (via empty_meta_index())
   and fill a metadata index.  It however suffers a data read error
   and aborts, invalidating the newly returned empty metadata index.
   It does this by setting the inode number of the index to zero,
   which means unused (zero is not a valid inode number).

2. When fill_meta_index() is subsequently called again on another
   read operation, locate_meta_index() returns the previous index
   because it matches the inode number of 0.  Because this index
   has been returned it is expected to have been filled, and because
   it hasn't been, an out of bounds access is performed.

This patch adds a sanity check which checks that the inode number
is not zero when the inode is created and returns -EINVAL if it is.

[phillip@squashfs.org.uk: whitespace fix]
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/32c114a58236fe[PII_REDACTED]4559f21f1dc96fd7; https://git.kernel.org/stable/c/4a1b6f89825e267e156ccaeba3d235edcac77f94; https://git.kernel.org/stable/c/5b99dea79650b50909c50aba24fbae00f203f013
CVE: CVE-2024-26984
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

nouveau: fix instmem race condition around ptr stores

Running a lot of VK CTS in parallel against nouveau, once every
few hours you might see something like this crash.

BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
PGD[PII_REDACTED]e6e067 P4D[PII_REDACTED]e6e067 PUD 109046067 PMD 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 7 PID: 53891 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27
Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021
RIP: 0010:gp100_vmm_pgt_mem+0xe3/0x180 [nouveau]
Code: c7 48 01 c8 49 89 45 58 85 d2 0f 84 95 00 00 00 41 0f b7 46 12 49 8b 7e 08 89 da 42 8d 2c f8 48 8b 47 08 41 83 c7 01 48 89 ee <48> 8b 40 08 ff d0 0f 1f 00 49 8b 7e 08 48 89 d9 48 8d 75 04 48 c1
RSP: 0000:ffffac20c5857838 EFLAGS: 00010202
RAX: [PII_REDACTED] RBX:[PII_REDACTED]4d8001 RCX: [PII_REDACTED]
RDX:[PII_REDACTED]4d8001 RSI:[PII_REDACTED]0006d8 RDI: ffffa07afe332180
RBP:[PII_REDACTED]0006d8 R08: ffffac20c5857ad0 R09:[PII_REDACTED]ffff10
R10: [PII_REDACTED] R11: ffffa07af27e2de0 R12:[PII_REDACTED]00001c
R13: ffffac20c5857ad0 R14: ffffa07a96fe9040 R15:[PII_REDACTED]00001c
FS:  00007fe395eed7c0(0000) GS:ffffa07e2c980000(0000) knlGS:[PII_REDACTED]
CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: [PII_REDACTED] CR3: 000000011febe001 CR4:[PII_REDACTED]3706f0
DR0: [PII_REDACTED] DR1: [PII_REDACTED] DR2: [PII_REDACTED]
DR3: [PII_REDACTED] DR6: 00000000fffe0ff0 DR7: [PII_REDACTED]
Call Trace:

...

 ? gp100_vmm_pgt_mem+0xe3/0x180 [nouveau]
 ? gp100_vmm_pgt_mem+0x37/0x180 [nouveau]
 nvkm_vmm_iter+0x351/0xa20 [nouveau]
 ? __pfx_nvkm_vmm_ref_ptes+0x10/0x10 [nouveau]
 ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau]
 ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau]
 ? __lock_acquire+0x3ed/0x2170
 ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau]
 nvkm_vmm_ptes_get_map+0xc2/0x100 [nouveau]
 ? __pfx_nvkm_vmm_ref_ptes+0x10/0x10 [nouveau]
 ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau]
 nvkm_vmm_map_locked+0x224/0x3a0 [nouveau]

Adding any sort of useful debug usually makes it go away, so I hand
wrote the function in a line, and debugged the asm.

Every so often pt->memory->ptrs is NULL. This ptrs ptr is set in
the nv50_instobj_acquire called from nvkm_kmap.

If Thread A and Thread B both get to nv50_instobj_acquire around
the same time, and Thread A hits the refcount_set line, and in
lockstep thread B succeeds at refcount_inc_not_zero, there is a
chance the ptrs value won't have been stored since refcount_set
is unordered. Force a memory barrier here, I picked smp_mb, since
we want it on all CPUs and it's write followed by a read.

v2: use paired smp_rmb/smp_wmb.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/13d76b2f443dc371842916dd8768009ff1594716; https://git.kernel.org/stable/c/1bc4825d4c3ec6abe43cf06c3c39d664d044cbf7; https://git.kernel.org/stable/c/21ca9539f09360fd83654f78f2c361f2f5ddcb52
CVE: CVE-2024-26985
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/xe: Fix bo leak in intel_fb_bo_framebuffer_init

Add a unreference bo in the error path, to prevent leaking a bo ref.

Return 0 on success to clarify the success path.

(cherry picked from commit a2f3d731be3893e730417ae3190760fcaffdf549)
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/652ead9b746a63e4e79d7ad66d3edf0a8a5b0c2f; https://git.kernel.org/stable/c/7d8ac0942c312abda43b407eff72d31747a7b472; https://git.kernel.org/stable/c/652ead9b746a63e4e79d7ad66d3edf0a8a5b0c2f
CVE: CVE-2024-26986
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amdkfd: Fix memory leak in create_process failure

Fix memory leak due to a leaked mmget reference on an error handling
code path that is triggered when attempting to create KFD processes
while a GPU reset is in progress.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/0dcd876411644da98a6b4d5a18d32ca94c15bdb5; https://git.kernel.org/stable/c/18921b205012568b45760753ad3146ddb9e2d4e2; https://git.kernel.org/stable/c/aa02d43367a9adf8c85fb382fea4171fb266c8d0
CVE: CVE-2024-26988
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

init/main.c: Fix potential static_command_line memory overflow

We allocate memory of size 'xlen + strlen(boot_command_line) + 1' for
static_command_line, but the strings copied into static_command_line are
extra_command_line and command_line, rather than extra_command_line and
boot_command_line.

When strlen(command_line) > strlen(boot_command_line), static_command_line
will overflow.

This patch just recovers strlen(command_line) which was miss-consolidated
with strlen(boot_command_line) in the commit f5c7310ac73e ("init/main: add
checks for the return value of memblock_alloc*()")
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/0dc727a4e[PII_REDACTED]8a22c3d01ccad2c8e1fe4; https://git.kernel.org/stable/c/2ef607ea103616aec0289f1b65d103d499fa903a; https://git.kernel.org/stable/c/46dad3c1e57897ab9228332f03e1c14798d2d3b9
CVE: CVE-2024-26990
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

KVM: x86/mmu: Write-protect L2 SPTEs in TDP MMU when clearing dirty status

Check kvm_mmu_page_ad_need_write_protect() when deciding whether to
write-protect or clear D-bits on TDP MMU SPTEs, so that the TDP MMU
accounts for any role-specific reasons for disabling D-bit dirty logging.

Specifically, TDP MMU SPTEs must be write-protected when the TDP MMU is
being used to run an L2 (i.e. L1 has disabled EPT) and PML is enabled.
KVM always disables PML when running L2, even when L1 and L2 GPAs are in
the some domain, so failing to write-protect TDP MMU SPTEs will cause
writes made by L2 to not be reflected in the dirty log.

[sean: massage shortlog and changelog, tweak ternary op formatting]
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2673dfb591a359c75080dd5af3da484b89320d22; https://git.kernel.org/stable/c/cdf811a937471af2d1facdf8ae80e5e68096f1ed; https://git.kernel.org/stable/c/e20bff0f1b2de9cfe303dd35ff46470104a87404
CVE: CVE-2024-26992
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

KVM: x86/pmu: Disable support for adaptive PEBS

Drop support for virtualizing adaptive PEBS, as KVM's implementation is
architecturally broken without an obvious/easy path forward, and because
exposing adaptive PEBS can leak host LBRs to the guest, i.e. can leak
host kernel addresses to the guest.

Bug #1 is that KVM doesn't account for the upper 32 bits of
IA32_FIXED_CTR_CTRL when (re)programming fixed counters, e.g
fixed_ctrl_field() drops the upper bits, reprogram_fixed_counters()
stores local variables as u8s and truncates the upper bits too, etc.

Bug #2 is that, because KVM _always_ sets precise_ip to a non-zero value
for PEBS events, perf will _always_ generate an adaptive record, even if
the guest requested a basic record.  Note, KVM will also enable adaptive
PEBS in individual *counter*, even if adaptive PEBS isn't exposed to the
guest, but this is benign as MSR_PEBS_DATA_CFG is guaranteed to be zero,
i.e. the guest will only ever see Basic records.

Bug #3 is in perf.  intel_pmu_disable_fixed() doesn't clear the upper
bits either, i.e. leaves ICL_FIXED_0_ADAPTIVE set, and
intel_pmu_enable_fixed() effectively doesn't clear ICL_FIXED_0_ADAPTIVE
either.  I.e. perf _always_ enables ADAPTIVE counters, regardless of what
KVM requests.

Bug #4 is that adaptive PEBS *might* effectively bypass event filters set
by the host, as "Updated Memory Access Info Group" records information
that might be disallowed by userspace via KVM_SET_PMU_EVENT_FILTER.

Bug #5 is that KVM doesn't ensure LBR MSRs hold guest values (or at least
zeros) when entering a vCPU with adaptive PEBS, which allows the guest
to read host LBRs, i.e. host RIPs/addresses, by enabling "LBR Entries"
records.

Disable adaptive PEBS support as an immediate fix due to the severity of
the LBR leak in particular, and because fixing all of the bugs will be
non-trivial, e.g. not suitable for backporting to stable kernels.

Note!  This will break live migration, but trying to make KVM play nice
with live migration would be quite complicated, wouldn't be guaranteed to
work (i.e. KVM might still kill/confuse the guest), and it's not clear
that there are any publicly available VMMs that support adaptive PEBS,
let alone live migrate VMs that support adaptive PEBS, e.g. QEMU doesn't
support PEBS in any capacity.
CVSS Score: 3.3 (LOW)
References: https://git.kernel.org/stable/c/037e48ceccf163899374b601afb6ae8d0bf1d2ac; https://git.kernel.org/stable/c/0fb74c00d140a66128afc0003785dcc57e69d312; https://git.kernel.org/stable/c/7a7650b3ac23e5fc8c990f00e94f787dc84e3175
CVE: CVE-2024-26993
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

fs: sysfs: Fix reference leak in sysfs_break_active_protection()

The sysfs_break_active_protection() routine has an obvious reference
leak in its error path.  If the call to kernfs_find_and_get() fails then
kn will be NULL, so the companion sysfs_unbreak_active_protection()
routine won't get called (and would only cause an access violation by
trying to dereference kn->parent if it was called).  As a result, the
reference to kobj acquired at the start of the function will never be
released.

Fix the leak by adding an explicit kobject_put() call when kn is NULL.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/43f00210cb257bcb0387e8caeb4b46375d67f30c; https://git.kernel.org/stable/c/57baab0f376bec8f54b0fe6beb8f77a57c228063; https://git.kernel.org/stable/c/5d43e072285e81b0b63cee7189b3357c7768a43b
CVE: CVE-2024-26994
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

speakup: Avoid crash on very long word

In case a console is set up really large and contains a really long word
(> 256 characters), we have to stop before the length of the word buffer.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0d130158db29f5e0b[PII_REDACTED]cf618896450a8; https://git.kernel.org/stable/c/0efb15c14c493263cb3a5f65f5ddfd4603d19a76; https://git.kernel.org/stable/c/6401038acfa24cba9c28cce410b7505efadd0222
CVE: CVE-2024-26995
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: typec: tcpm: Correct the PDO counting in pd_set

Off-by-one errors happen because nr_snk_pdo and nr_src_pdo are
incorrectly added one. The index of the loop is equal to the number of
PDOs to be updated when leaving the loop and it doesn't need to be added
one.

When doing the power negotiation, TCPM relies on the "nr_snk_pdo" as
the size of the local sink PDO array to match the Source capabilities
of the partner port. If the off-by-one overflow occurs, a wrong RDO
might be sent and unexpected power transfer might happen such as over
voltage or over current (than expected).

"nr_src_pdo" is used to set the Rp level when the port is in Source
role. It is also the array size of the local Source capabilities when
filling up the buffer which will be sent as the Source PDOs (such as
in Power Negotiation). If the off-by-one overflow occurs, a wrong Rp
level might be set and wrong Source PDOs will be sent to the partner
port. This could potentially cause over current or port resets.
CVSS Score: 7.8 (HIGH)
CWE: CWE-193
References: https://git.kernel.org/stable/c/c4128304c2169b4664ed6fb6200f228cead2ab70; https://git.kernel.org/stable/c/f3da3192cdd3fefe213390e976eec424a8e270b5; https://git.kernel.org/stable/c/c4128304c2169b4664ed6fb6200f228cead2ab70
CVE: CVE-2024-26996
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: gadget: f_ncm: Fix UAF ncm object at re-bind after usb ep transport error

When ncm function is working and then stop usb0 interface for link down,
eth_stop() is called. At this piont, accidentally if usb transport error
should happen in usb_ep_enable(), 'in_ep' and/or 'out_ep' may not be enabled.

After that, ncm_disable() is called to disable for ncm unbind
but gether_disconnect() is never called since 'in_ep' is not enabled.

As the result, ncm object is released in ncm unbind
but 'dev->port_usb' associated to 'ncm->port' is not NULL.

And when ncm bind again to recover netdev, ncm object is reallocated
but usb0 interface is already associated to previous released ncm object.

Therefore, once usb0 interface is up and eth_start_xmit() is called,
released ncm object is dereferrenced and it might cause use-after-free memory.

[function unlink via configfs]
  usb0: eth_stop dev->port_usb=ffffff9b179c3200
  --> error happens in usb_ep_enable().
  NCM: ncm_disable: ncm=ffffff9b179c3200
  --> no gether_disconnect() since ncm->port.in_ep->enabled is false.
  NCM: ncm_unbind: ncm unbind ncm=ffffff9b179c3200
  NCM: ncm_free: ncm free ncm=ffffff9b179c3200   <-- released ncm

[function link via configfs]
  NCM: ncm_alloc: ncm alloc ncm=ffffff9ac4f8a000
  NCM: ncm_bind: ncm bind ncm=ffffff9ac4f8a000
  NCM: ncm_set_alt: ncm=ffffff9ac4f8a000 alt=0
  usb0: eth_open dev->port_usb=ffffff9b179c3200  <-- previous released ncm
  usb0: eth_start dev->port_usb=ffffff9b179c3200 <--
  eth_start_xmit()
  --> dev->wrap()
  Unable to handle kernel paging request at virtual address dead[PII_REDACTED]4f

This patch addresses the issue by checking if 'ncm->netdev' is not NULL at
ncm_disable() to call gether_disconnect() to deassociate 'dev->port_usb'.
It's more reasonable to check 'ncm->netdev' to call gether_connect/disconnect
rather than check 'ncm->port.in_ep->enabled' since it might not be enabled
but the gether connection might be established.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/0588bbbd718a8130b98c54518f1e0b569ce60a93; https://git.kernel.org/stable/c/6334b8e4553cc69f51e383c9de545082213d785e; https://git.kernel.org/stable/c/7250326cbb1f4f90391ac511a126b936cefb5bb7
CVE: CVE-2024-26997
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: dwc2: host: Fix dereference issue in DDMA completion flow.

Fixed variable dereference issue in DDMA completion flow.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/257d313e37d66c3bcc87197fb5b8549129c45dfe; https://git.kernel.org/stable/c/26fde0ea40dda1b08fad3bc0a43f122f6dd8bddf; https://git.kernel.org/stable/c/55656b2afd5f1efcec4245f3e7e814c2a9ef53f6
CVE: CVE-2024-26998
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

serial: core: Clearing the circular buffer before NULLifying it

The circular buffer is NULLified in uart_tty_port_shutdown()
under the spin lock. However, the PM or other timer based callbacks
may still trigger after this event without knowning that buffer pointer
is not valid. Since the serial code is a bit inconsistent in checking
the buffer state (some rely on the head-tail positions, some on the
buffer pointer), it's better to have both aligned, i.e. buffer pointer
to be NULL and head-tail possitions to be the same, meaning it's empty.
This will prevent asynchronous calls to dereference NULL pointer as
reported recently in 8250 case:

  BUG: kernel NULL pointer dereference, address: 00000cf5
  Workqueue: pm pm_runtime_work
  EIP: serial8250_tx_chars (drivers/tty/serial/8250/8250_port.c:1809)
  ...
  ? serial8250_tx_chars (drivers/tty/serial/8250/8250_port.c:1809)
  __start_tx (drivers/tty/serial/8250/8250_port.c:1551)
  serial8250_start_tx (drivers/tty/serial/8250/8250_port.c:1654)
  serial_port_runtime_suspend (include/linux/serial_core.h:667 drivers/tty/serial/serial_port.c:63)
  __rpm_callback (drivers/base/power/runtime.c:393)
  ? serial_port_remove (drivers/tty/serial/serial_port.c:50)
  rpm_suspend (drivers/base/power/runtime.c:447)

The proposed change will prevent ->start_tx() to be called during
suspend on shut down port.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/7ae7104d54342433a3a73975f6569beefdd86350; https://git.kernel.org/stable/c/9cf7ea2eeb745213dc2a04103e426b960e807940; https://git.kernel.org/stable/c/bb1118905e875c111d7ccef9aee86ac5e4e7f985
CVE: CVE-2024-26999
Published: 2024-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

serial/pmac_zilog: Remove flawed mitigation for rx irq flood

The mitigation was intended to stop the irq completely. That may be
better than a hard lock-up but it turns out that you get a crash anyway
if you're using pmac_zilog as a serial console:

ttyPZ0: pmz: rx irq flood !
BUG: spinlock recursion on CPU#0, swapper/0

That's because the pr_err() call in pmz_receive_chars() results in
pmz_console_write() attempting to lock a spinlock already locked in
pmz_interrupt(). With CONFIG_DEBUG_SPINLOCK=y, this produces a fatal
BUG splat. The spinlock in question is the one in struct uart_port.

Even when it's not fatal, the serial port rx function ceases to work.
Also, the iteration limit doesn't play nicely with QEMU, as can be
seen in the bug report linked below.

A web search for other reports of the error message "pmz: rx irq flood"
didn't produce anything. So I don't think this code is needed any more.
Remove it.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/1be[PII_REDACTED]bfbf461c92a5bcdb1723f2e4907; https://git.kernel.org/stable/c/52aaf1ff14622a04148dbb9ccce6d9de5d534ea7; https://git.kernel.org/stable/c/69a02273e288011b521ee7c1f3ab2c23fda633ce