deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2023-54253
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

btrfs: set page extent mapped after read_folio in relocate_one_page

One of the CI runs triggered the following panic

  assertion failed: PagePrivate(page) && page->private, in fs/btrfs/subpage.c:229
  ------------[ cut here ]------------
  kernel BUG at fs/btrfs/subpage.c:229!
  Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
  CPU: 0 PID: 923660 Comm: btrfs Not tainted 6.5.0-rc3+ #1
  pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
  pc : btrfs_subpage_assert+0xbc/0xf0
  lr : btrfs_subpage_assert+0xbc/0xf0
  sp : ffff[PII_REDACTED]20
  x29: ffff[PII_REDACTED]20 x28: ffff[PII_REDACTED]b4 x27: 000000000c280000
  x26: 00000001b5d00000 x25: 000000000c281000 x24: 000000000c281fff
  x23: [PII_REDACTED] x22: [PII_REDACTED] x21: ffffff42b95bf880
  x20: ffff42b9528e0000 x19: [PII_REDACTED] x18: ffffffffffffffff
  x17: 667274622f736620 x16: 6e69202c65746176 x15: [PII_REDACTED]
  x14: [PII_REDACTED] x13:[PII_REDACTED]2672d7 x12: [PII_REDACTED]
  x11: ffffcd3f0ccd9204 x10: ffffcd3f0554ae50 x9 : ffffcd3f0379528c
  x8 : ffff[PII_REDACTED]28 x7 : [PII_REDACTED] x6 : ffffcd3f091771e8
  x5 : ffff42b97f333948 x4 : [PII_REDACTED] x3 : [PII_REDACTED]
  x2 : [PII_REDACTED] x1 : ffff42b9556cde80 x0 :[PII_REDACTED]00004f
  Call trace:
   btrfs_subpage_assert+0xbc/0xf0
   btrfs_subpage_set_dirty+0x38/0xa0
   btrfs_page_set_dirty+0x58/0x88
   relocate_one_page+0x204/0x5f0
   relocate_file_extent_cluster+0x11c/0x180
   relocate_data_extent+0xd0/0xf8
   relocate_block_group+0x3d0/0x4e8
   btrfs_relocate_block_group+0x2d8/0x490
   btrfs_relocate_chunk+0x54/0x1a8
   btrfs_balance+0x7f4/0x1150
   btrfs_ioctl+0x10f0/0x20b8
   __arm64_sys_ioctl+0x120/0x11d8
   invoke_syscall.constprop.0+0x80/0xd8
   do_el0_svc+0x6c/0x158
   el0_svc+0x50/0x1b0
   el0t_64_sync_handler+0x120/0x130
   el0t_64_sync+0x194/0x198
  Code: 91098021 b0007fa0 91346000 97e9c6d2 (d4210000)

This is the same problem outlined in 17b17fcd6d44 ("btrfs:
set_page_extent_mapped after read_folio in btrfs_cont_expand") , and the
fix is the same.  I originally looked for the same pattern elsewhere in
our code, but mistakenly skipped over this code because I saw the page
cache readahead before we set_page_extent_mapped, not realizing that
this was only in the !page case, that we can still end up with a
!uptodate page and then do the btrfs_read_folio further down.

The fix here is the same as the above mentioned patch, move the
set_page_extent_mapped call to after the btrfs_read_folio() block to
make sure that we have the subpage blocksize stuff setup properly before
using the page.
References: https://git.kernel.org/stable/c/08daa38ca212d87f77beae839bc9be71079c7abf; https://git.kernel.org/stable/c/9d1e020ed9649cf140fcfafd052cfdcce9e9d67d; https://git.kernel.org/stable/c/e7f1326cc24e22b38afc3acd328480a1183f9e79
CVE: CVE-2023-54254
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/ttm: Don't leak a resource on eviction error

On eviction errors other than -EMULTIHOP we were leaking a resource.
Fix.

v2:
- Avoid yet another goto (Andi Shyti)
References: https://git.kernel.org/stable/c/6aea0032380bbb1efebd598ad733d[PII_REDACTED]; https://git.kernel.org/stable/c/7738335d73d0686ec8995e0448e5d1b48cffb2a4; https://git.kernel.org/stable/c/e8188c461ee015ba0b9ab2fc82dbd5ebca5a5532
CVE: CVE-2023-54255
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

sh: dma: Fix DMA channel offset calculation

Various SoCs of the SH3, SH4 and SH4A family, which use this driver,
feature a differing number of DMA channels, which can be distributed
between up to two DMAC modules. The existing implementation fails to
correctly accommodate for all those variations, resulting in wrong
channel offset calculations and leading to kernel panics.

Rewrite dma_base_addr() in order to properly calculate channel offsets
in a DMAC module. Fix dmaor_read_reg() and dmaor_write_reg(), so that
the correct DMAC module base is selected for the DMAOR register.
References: https://git.kernel.org/stable/c/196f6c71905aa384c0177acf194a1144d480333b; https://git.kernel.org/stable/c/479380acfa63247b5ac62476138f847aefc62692; https://git.kernel.org/stable/c/[PII_REDACTED]735c1f1619f08e5bc1592418e7c878
CVE: CVE-2023-54256
Published: 2025-12-30
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2023-54258
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

cifs: fix potential oops in cifs_oplock_break

With deferred close we can have closes that race with lease breaks,
and so with the current checks for whether to send the lease response,
oplock_response(), this can mean that an unmount (kill_sb) can occur
just before we were checking if the tcon->ses is valid.  See below:

[Fri Aug  4 04:12:50 2023] RIP: 0010:cifs_oplock_break+0x1f7/0x5b0 [cifs]
[Fri Aug  4 04:12:50 2023] Code: 7d a8 48 8b 7d c0 c0 e9 02 48 89 45 b8 41 89 cf e8 3e f5 ff ff 4c 89 f7 41 83 e7 01 e8 82 b3 03 f2 49 8b 45 50 48 85 c0 74 5e <48> 83 78 60 00 74 57 45 84 ff 75 52 48 8b 43 98 48 83 eb 68 48 39
[Fri Aug  4 04:12:50 2023] RSP: 0018:ffffb30607ddbdf8 EFLAGS: 00010206
[Fri Aug  4 04:12:50 2023] RAX: 632d223d32612022 RBX: ffff97136944b1e0 RCX: [PII_REDACTED]
[Fri Aug  4 04:12:50 2023] RDX: [PII_REDACTED] RSI: [PII_REDACTED] RDI: ffff97136944b188
[Fri Aug  4 04:12:50 2023] RBP: ffffb30607ddbe58 R08: [PII_REDACTED] R09: ffffffffc08e0900
[Fri Aug  4 04:12:50 2023] R10: [PII_REDACTED] R11:[PII_REDACTED]00000f R12: ffff97136944b138
[Fri Aug  4 04:12:50 2023] R13: ffff97149147c000 R14: ffff97136944b188 R15: [PII_REDACTED]
[Fri Aug  4 04:12:50 2023] FS:  [PII_REDACTED](0000) GS:ffff9714f7c00000(0000) knlGS:[PII_REDACTED]
[Fri Aug  4 04:12:50 2023] CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
[Fri Aug  4 04:12:50 2023] CR2: 00007fd8de9c7590 CR3:[PII_REDACTED]28e000 CR4:[PII_REDACTED]350ef0
[Fri Aug  4 04:12:50 2023] Call Trace:
[Fri Aug  4 04:12:50 2023]  <TASK>
[Fri Aug  4 04:12:50 2023]  process_one_work+0x225/0x3d0
[Fri Aug  4 04:12:50 2023]  worker_thread+0x4d/0x3e0
[Fri Aug  4 04:12:50 2023]  ? process_one_work+0x3d0/0x3d0
[Fri Aug  4 04:12:50 2023]  kthread+0x12a/0x150
[Fri Aug  4 04:12:50 2023]  ? set_kthread_struct+0x50/0x50
[Fri Aug  4 04:12:50 2023]  ret_from_fork+0x22/0x30
[Fri Aug  4 04:12:50 2023]  </TASK>

To fix this change the ordering of the checks before sending the oplock_response
to first check if the openFileList is empty.
References: https://git.kernel.org/stable/c/5ee28bcfbaacf289eb25c662a2862542ea6ce6a7; https://git.kernel.org/stable/c/6b67a6d2e50634fe127e656147c81915955e9f5e; https://git.kernel.org/stable/c/b99f490ea87ebcca3a429fd8837067feb56a4c7c
CVE: CVE-2023-54259
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

soundwire: bus: Fix unbalanced pm_runtime_put() causing usage count underflow

This reverts commit
443a98e649b4 ("soundwire: bus: use pm_runtime_resume_and_get()")

Change calls to pm_runtime_resume_and_get() back to pm_runtime_get_sync().
This fixes a usage count underrun caused by doing a pm_runtime_put() even
though pm_runtime_resume_and_get() returned an error.

The three affected functions ignore -EACCES error from trying to get
pm_runtime, and carry on, including a put at the end of the function.
But pm_runtime_resume_and_get() does not increment the usage count if it
returns an error. So in the -EACCES case you must not call
pm_runtime_put().

The documentation for pm_runtime_get_sync() says:
 "Consider using pm_runtime_resume_and_get() ...  as this is likely to
 result in cleaner code."

In this case I don't think it results in cleaner code because the
pm_runtime_put() at the end of the function would have to be conditional on
the return value from pm_runtime_resume_and_get() at the top of the
function.

pm_runtime_get_sync() doesn't have this problem because it always
increments the count, so always needs a put. The code can just flow through
and do the pm_runtime_put() unconditionally.
References: https://git.kernel.org/stable/c/203aa4374c433159f163acde2d0bd4118f23bbaf; https://git.kernel.org/stable/c/4e5e9da139c007dfc397a159093b4c4187ee67fa; https://git.kernel.org/stable/c/e[PII_REDACTED]e88969f5f69cd0571eb4f6984403c
CVE: CVE-2023-54260
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

cifs: Fix lost destroy smbd connection when MR allocate failed

If the MR allocate failed, the smb direct connection info is NULL,
then smbd_destroy() will directly return, then the connection info
will be leaked.

Let's set the smb direct connection info to the server before call
smbd_destroy().
References: https://git.kernel.org/stable/c/04b7e13b8a13264282f874db5378fc3d3253cfac; https://git.kernel.org/stable/c/324c0c34fff1affd436e509325cb[PII_REDACTED]4e; https://git.kernel.org/stable/c/46cd6c639cddba2bd2d810ceb16bb20374ad75b0
CVE: CVE-2023-54261
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amdkfd: Add missing gfx11 MQD manager callbacks

mqd_stride function was introduced in commit 2f77b9a242a2
("drm/amdkfd: Update MQD management on multi XCC setup")
but not assigned for gfx11. Fixes a NULL dereference in debugfs.
References: https://git.kernel.org/stable/c/399b73d6b7720a9eae68a333193b53ed4f432fe5; https://git.kernel.org/stable/c/e9dca969b2426702a73719ab9207e43c6d80b581
CVE: CVE-2023-54263
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/nouveau/kms/nv50-: init hpd_irq_lock for PIOR DP

Fixes OOPS on boards with ANX9805 DP encoders.
References: https://git.kernel.org/stable/c/92d48ce21645267c[PII_REDACTED]31cd2b648dad0f; https://git.kernel.org/stable/c/ea293f823a8805735d9e00124df81a8f448ed1ae
CVE: CVE-2023-54264
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

fs/sysv: Null check to prevent null-ptr-deref bug

sb_getblk(inode->i_sb, parent) return a null ptr and taking lock on
that leads to the null-ptr-deref bug.
References: https://git.kernel.org/stable/c/0a44ceba77c3267f8505dda102a59367dc24caee; https://git.kernel.org/stable/c/1416eebaad80bdc85ad9f97f27242011b031e2a9; https://git.kernel.org/stable/c/7f740bc696d4617f8ee44565e8ac0d36278a1e91
CVE: CVE-2023-54266
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

media: dvb-usb: m920x: Fix a potential memory leak in m920x_i2c_xfer()

'read' is freed when it is known to be NULL, but not when a read error
occurs.

Revert the logic to avoid a small leak, should a m920x_read() call fail.
References: https://git.kernel.org/stable/c/2b6e20ef0585a467c24c7e4fde28518e5b33225a; https://git.kernel.org/stable/c/2cc9f11aeae2887a4db25c27323fc445f4b49e86; https://git.kernel.org/stable/c/4feed3dfca722c6d74865a37cab853c58e6aa190
CVE: CVE-2023-54267
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

powerpc/pseries: Rework lppaca_shared_proc() to avoid DEBUG_PREEMPT

lppaca_shared_proc() takes a pointer to the lppaca which is typically
accessed through get_lppaca().  With DEBUG_PREEMPT enabled, this leads
to checking if preemption is enabled, for example:

  BUG: using smp_processor_id() in preemptible [00000000] code: grep/10693
  caller is lparcfg_data+0x408/0x19a0
  CPU: 4 PID: 10693 Comm: grep Not tainted 6.5.0-rc3 #2
  Call Trace:
    dump_stack_lvl+0x154/0x200 (unreliable)
    check_preemption_disabled+0x214/0x220
    lparcfg_data+0x408/0x19a0
    ...

This isn't actually a problem however, as it does not matter which
lppaca is accessed, the shared proc state will be the same.
vcpudispatch_stats_procfs_init() already works around this by disabling
preemption, but the lparcfg code does not, erroring any time
/proc/powerpc/lparcfg is accessed with DEBUG_PREEMPT enabled.

Instead of disabling preemption on the caller side, rework
lppaca_shared_proc() to not take a pointer and instead directly access
the lppaca, bypassing any potential preemption checks.

[mpe: Rework to avoid needing a definition in paca.h and lppaca.h]
References: https://git.kernel.org/stable/c/2935443dc9c28499223d8c881474259e4b998f2a; https://git.kernel.org/stable/c/3c5e8e666794d7dde6d14ea846c6c04f2bb34900; https://git.kernel.org/stable/c/4c8568cf4c45b415854195c8832b557cdefba57a
CVE: CVE-2023-54268
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

debugobjects: Don't wake up kswapd from fill_pool()

syzbot is reporting a lockdep warning in fill_pool() because the allocation
from debugobjects is using GFP_ATOMIC, which is (__GFP_HIGH | __GFP_KSWAPD_RECLAIM)
and therefore tries to wake up kswapd, which acquires kswapd_wait::lock.

Since fill_pool() might be called with arbitrary locks held, fill_pool()
should not assume that acquiring kswapd_wait::lock is safe.

Use __GFP_HIGH instead and remove __GFP_NORETRY as it is pointless for
!__GFP_DIRECT_RECLAIM allocation.
References: https://git.kernel.org/stable/c/4c088d30a72d9b8f9c6ae[PII_REDACTED]e4075cb00; https://git.kernel.org/stable/c/aee97eec[PII_REDACTED]6c704f66cdf2881cbd2fe1; https://git.kernel.org/stable/c/be646802b3dc408c4dc72a3ac32c3f4a0282414d
CVE: CVE-2023-54269
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

SUNRPC: double free xprt_ctxt while still in use

When an RPC request is deferred, the rq_xprt_ctxt pointer is moved out
of the svc_rqst into the svc_deferred_req.
When the deferred request is revisited, the pointer is copied into
the new svc_rqst - and also remains in the svc_deferred_req.

In the (rare?) case that the request is deferred a second time, the old
svc_deferred_req is reused - it still has all the correct content.
However in that case the rq_xprt_ctxt pointer is NOT cleared so that
when xpo_release_xprt is called, the ctxt is freed (UDP) or possible
added to a free list (RDMA).
When the deferred request is revisited for a second time, it will
reference this ctxt which may be invalid, and the free the object a
second time which is likely to oops.

So change svc_defer() to *always* clear rq_xprt_ctxt, and assert that
the value is now stored in the svc_deferred_req.
References: https://git.kernel.org/stable/c/[PII_REDACTED]e87108a[PII_REDACTED]5ef0c9307dc5e; https://git.kernel.org/stable/c/e0c648627322a4c7e018e5c7f837c3c03e297dbb; https://git.kernel.org/stable/c/eb8d3a2c809abd73ab0a060fe971d6b9019aa3c1
CVE: CVE-2023-54272
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

fs/ntfs3: Fix a possible null-pointer dereference in ni_clear()

In a previous commit c1006bd13146, ni->mi.mrec in ni_write_inode()
could be NULL, and thus a NULL check is added for this variable.

However, in the same call stack, ni->mi.mrec can be also dereferenced
in ni_clear():

ntfs_evict_inode(inode)
  ni_write_inode(inode, ...)
    ni = ntfs_i(inode);
    is_rec_inuse(ni->mi.mrec) -> Add a NULL check by previous commit
  ni_clear(ntfs_i(inode))
    is_rec_inuse(ni->mi.mrec) -> No check

Thus, a possible null-pointer dereference may exist in ni_clear().
To fix it, a NULL check is added in this function.
References: https://git.kernel.org/stable/c/20f9bfc664d6a478f9a5bbc0c380f80f7a1a06c6; https://git.kernel.org/stable/c/39c[PII_REDACTED]ca[PII_REDACTED]3ca222e7753a71b; https://git.kernel.org/stable/c/e7675f85a92233136c630000a0b7cf97826705da
CVE: CVE-2023-54273
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

xfrm: Fix leak of dev tracker

At the stage of direction checks, the netdev reference tracker is
already initialized, but released with wrong *_put() call.
References: https://git.kernel.org/stable/c/7d16c515059b3746f2d6a24a74c3ba786a68c2a1; https://git.kernel.org/stable/c/ec8f32ad9a65a8cbb465b69e154aaec9d2fe45c4
CVE: CVE-2023-54274
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

RDMA/srpt: Add a check for valid 'mad_agent' pointer

When unregistering MAD agent, srpt module has a non-null check
for 'mad_agent' pointer before invoking ib_unregister_mad_agent().
This check can pass if 'mad_agent' variable holds an error value.
The 'mad_agent' can have an error value for a short window when
srpt_add_one() and srpt_remove_one() is executed simultaneously.

In srpt module, added a valid pointer check for 'sport->mad_agent'
before unregistering MAD agent.

This issue can hit when RoCE driver unregisters ib_device

Stack Trace:
------------
BUG: kernel NULL pointer dereference, address:[PII_REDACTED]00004d
PGD 145003067 P4D 145003067 PUD 2324fe067 PMD 0
Oops: 0002 [#1] PREEMPT SMP NOPTI
CPU: 10 PID: 4459 Comm: kworker/u80:0 Kdump: loaded Tainted: P
Hardware name: Dell Inc. PowerEdge R640/06NR82, BIOS 2.5.4 01/13/2020
Workqueue: bnxt_re bnxt_re_task [bnxt_re]
RIP: 0010:_raw_spin_lock_irqsave+0x19/0x40
Call Trace:
  ib_unregister_mad_agent+0x46/0x2f0 [ib_core]
  IPv6: ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready
  ? __schedule+0x20b/0x560
  srpt_unregister_mad_agent+0x93/0xd0 [ib_srpt]
  srpt_remove_one+0x20/0x150 [ib_srpt]
  remove_client_context+0x88/0xd0 [ib_core]
  bond0: (slave p2p1): link status definitely up, 100000 Mbps full duplex
  disable_device+0x8a/0x160 [ib_core]
  bond0: active interface up!
  ? kernfs_name_hash+0x12/0x80
 (NULL device *): Bonding Info Received: rdev: 000000006c0b8247
  __ib_unregister_device+0x42/0xb0 [ib_core]
 (NULL device *):         Master: mode: 4 num_slaves:2
  ib_unregister_device+0x22/0x30 [ib_core]
 (NULL device *):         Slave: id: 105069936 name:p2p1 link:0 state:0
  bnxt_re_stopqps_and_ib_uninit+0x83/0x90 [bnxt_re]
  bnxt_re_alloc_lag+0x12e/0x4e0 [bnxt_re]
References: https://git.kernel.org/stable/c/00cc21e32ea1b8ebbabf5d645da9378d986bf8ba; https://git.kernel.org/stable/c/4323aaedeba32076e652aad056afd7885bb96bb7; https://git.kernel.org/stable/c/5f6ef2a574b0e0e0ea46ed[PII_REDACTED]df9d0bf9
CVE: CVE-2023-54275
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: ath11k: Fix memory leak in ath11k_peer_rx_frag_setup

crypto_alloc_shash() allocates resources, which should be released by
crypto_free_shash(). When ath11k_peer_find() fails, there has memory
leak. Add missing crypto_free_shash() to fix this.
References: https://git.kernel.org/stable/c/137963e3b95776f1d57c62f249a93fe47e019a22; https://git.kernel.org/stable/c/53c8a256e5d3f31d80186de03a3d2a7f747b2aa0; https://git.kernel.org/stable/c/64a78ec4f4579798d8e885aca9bdd707bca6b16b
CVE: CVE-2023-54276
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

nfsd: move init of percpu reply_cache_stats counters back to nfsd_init_net

Commit f5f9d4a314da ("nfsd: move reply cache initialization into nfsd
startup") moved the initialization of the reply cache into nfsd startup,
but didn't account for the stats counters, which can be accessed before
nfsd is ever started. The result can be a NULL pointer dereference when
someone accesses /proc/fs/nfsd/reply_cache_stats while nfsd is still
shut down.

This is a regression and a user-triggerable oops in the right situation:

- non-x86_64 arch
- /proc/fs/nfsd is mounted in the namespace
- nfsd is not started in the namespace
- unprivileged user calls "cat /proc/fs/nfsd/reply_cache_stats"

Although this is easy to trigger on some arches (like aarch64), on
x86_64, calling this_cpu_ptr(NULL) evidently returns a pointer to the
fixed_percpu_data. That struct looks just enough like a newly
initialized percpu var to allow nfsd_reply_cache_stats_show to access
it without Oopsing.

Move the initialization of the per-net+per-cpu reply-cache counters
back into nfsd_init_net, while leaving the rest of the reply cache
allocations to be done at nfsd startup time.

Kudos to Eirik who did most of the legwork to track this down.
References: https://git.kernel.org/stable/c/3025d489f9c8984d1bf5916c4a20097ed80fca5c; https://git.kernel.org/stable/c/66a178177b2b3bb1d71e854c5e7bbb320eb0e566; https://git.kernel.org/stable/c/768c408594b52d8531e1a8ab62e5620c19213e73
CVE: CVE-2023-54277
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

fbdev: udlfb: Fix endpoint check

The syzbot fuzzer detected a problem in the udlfb driver, caused by an
endpoint not having the expected type:

usb 1-1: Read EDID byte 0 failed: -71
usb 1-1: Unable to get valid EDID from device/display
------------[ cut here ]------------
usb 1-1: BOGUS urb xfer, pipe 3 != type 1
WARNING: CPU: 0 PID: 9 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880
drivers/usb/core/urb.c:504
Modules linked in:
CPU: 0 PID: 9 Comm: kworker/0:1 Not tainted
6.4.0-rc1-syzkaller-00016-ga4422ff22142 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
04/28/2023
Workqueue: usb_hub_wq hub_event
RIP: 0010:usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504
...
Call Trace:
 <TASK>
 dlfb_submit_urb+0x92/0x180 drivers/video/fbdev/udlfb.c:1980
 dlfb_set_video_mode+0x21f0/0x2950 drivers/video/fbdev/udlfb.c:315
 dlfb_ops_set_par+0x2a7/0x8d0 drivers/video/fbdev/udlfb.c:1111
 dlfb_usb_probe+0x149a/0x2710 drivers/video/fbdev/udlfb.c:1743

The current approach for this issue failed to catch the problem
because it only checks for the existence of a bulk-OUT endpoint; it
doesn't check whether this endpoint is the one that the driver will
actually use.

We can fix the problem by instead checking that the endpoint used by
the driver does exist and is bulk-OUT.
References: https://git.kernel.org/stable/c/1522dc58bff87af79461b96d90ec122e9e726004; https://git.kernel.org/stable/c/58ecc165abdaed85447455e6dc396758e8c6f219; https://git.kernel.org/stable/c/9e12c58a5ece41be72157cef348576b135c9fc72
CVE: CVE-2023-54278
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

s390/vmem: split pages when debug pagealloc is enabled

Since commit bb1520d581a3 ("s390/mm: start kernel with DAT enabled")
the kernel crashes early during boot when debug pagealloc is enabled:

mem auto-init: stack:off, heap alloc:off, heap free:off
addressing exception: 0005 ilc:2 [#1] SMP DEBUG_PAGEALLOC
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 6.5.0-rc3-09759-gc5666c912155 #630
[..]
Krnl Code:[PII_REDACTED]1325f6: ec[PII_REDACTED] cgrj %r5,%r6,8,[PII_REDACTED]13263e
          [PII_REDACTED]1325fc: eb880002000c srlg %r8,%r8,2
          #[PII_REDACTED]: b2210051     ipte %r5,%r1,%r0,0
          >[PII_REDACTED]: b90400d1     lgr %r13,%r1
          [PII_REDACTED]13260a: 41605008     la %r6,8(%r5)
          [PII_REDACTED]13260e: a7db1000     aghi %r13,4096
           [PII_REDACTED]: b221006d     ipte %r6,%r13,%r0,0
           [PII_REDACTED]: e3d0d0000171 lay %r13,4096(%r13)

Call Trace:
 __kernel_map_pages+0x14e/0x320
 __free_pages_ok+0x23a/0x5a8)
 free_low_memory_core_early+0x214/0x2c8
 memblock_free_all+0x28/0x58
 mem_init+0xb6/0x228
 mm_core_init+0xb6/0x3b0
 start_kernel+0x1d2/0x5a8
 startup_continue+0x36/0x40
Kernel panic - not syncing: Fatal exception: panic_on_oops

This is caused by using large mappings on machines with EDAT1/EDAT2. Add
the code to split the mappings into 4k pages if debug pagealloc is enabled
by CONFIG_DEBUG_PAGEALLOC_ENABLE_DEFAULT or the debug_pagealloc kernel
command line option.
References: https://git.kernel.org/stable/c/601e467e29a960f7ab7ec4075afc6a68c3532a65; https://git.kernel.org/stable/c/edc1e4b6e26536868ef819a735e04a5b32c10589