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

power: supply: bq27xxx: Fix poll_interval handling and races on remove

Before this patch bq27xxx_battery_teardown() was setting poll_interval = 0
to avoid bq27xxx_battery_update() requeuing the delayed_work item.

There are 2 problems with this:

1. If the driver is unbound through sysfs, rather then the module being
   rmmod-ed, this changes poll_interval unexpectedly

2. This is racy, after it being set poll_interval could be changed
   before bq27xxx_battery_update() checks it through
   /sys/module/bq27xxx_battery/parameters/poll_interval

Fix this by added a removed attribute to struct bq27xxx_device_info and
using that instead of setting poll_interval to 0.

There also is another poll_interval related race on remove(), writing
/sys/module/bq27xxx_battery/parameters/poll_interval will requeue
the delayed_work item for all devices on the bq27xxx_battery_devices
list and the device being removed was only removed from that list
after cancelling the delayed_work item.

Fix this by moving the removal from the bq27xxx_battery_devices list
to before cancelling the delayed_work item.
References: https://git.kernel.org/stable/c/0c5f4cec759679c290720fbcf6bb81768e21c95b; https://git.kernel.org/stable/c/465d919151a1e8d40daf366b868914f59d073211; https://git.kernel.org/stable/c/4c9615474fb0a41cfad658d78db3c9ec70912969
CVE: CVE-2023-54081
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

xen: speed up grant-table reclaim

When a grant entry is still in use by the remote domain, Linux must put
it on a deferred list.  Normally, this list is very short, because
the PV network and block protocols expect the backend to unmap the grant
first.  However, Qubes OS's GUI protocol is subject to the constraints
of the X Window System, and as such winds up with the frontend unmapping
the window first.  As a result, the list can grow very large, resulting
in a massive memory leak and eventual VM freeze.

To partially solve this problem, make the number of entries that the VM
will attempt to free at each iteration tunable.  The default is still
10, but it can be overridden via a module parameter.

This is Cc: stable because (when combined with appropriate userspace
changes) it fixes a severe performance and stability problem for Qubes
OS users.
References: https://git.kernel.org/stable/c/c04e9894846c663f3278a414f34416e6e45bbe68; https://git.kernel.org/stable/c/c76d96c555895ac602c1587b001e5cf656abc371; https://git.kernel.org/stable/c/cd1a8952ff529adc210e62306849fd6f256608c0
CVE: CVE-2023-54082
Published: 2025-12-24
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2023-54083
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

phy: tegra: xusb: Clear the driver reference in usb-phy dev

For the dual-role port, it will assign the phy dev to usb-phy dev and
use the port dev driver as the dev driver of usb-phy.

When we try to destroy the port dev, it will destroy its dev driver
as well. But we did not remove the reference from usb-phy dev. This
might cause the use-after-free issue in KASAN.
References: https://git.kernel.org/stable/c/238edc04ddb9d272b38f5419bcd419ad3b92b91b; https://git.kernel.org/stable/c/[PII_REDACTED]7ad58fd6b06d2883da73c3f2df9631; https://git.kernel.org/stable/c/b6a107c52073496d2e5d2837915f59fb3103832f
CVE: CVE-2023-54084
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

ALSA: firewire-digi00x: prevent potential use after free

This code was supposed to return an error code if init_stream()
failed, but it instead freed dg00x->rx_stream and returned success.
This potentially leads to a use after free.
References: https://git.kernel.org/stable/c/13c5fa1248bf06e95a25907c1be83948b8c44c50; https://git.kernel.org/stable/c/5009aead17f060753428e249eb0246eb1c2f8b86; https://git.kernel.org/stable/c/67148395efa2c1fb20e98fca359b20e7a6c81fe4
CVE: CVE-2023-54085
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

mptcp: fix NULL pointer dereference on fastopen early fallback

In case of early fallback to TCP, subflow_syn_recv_sock() deletes
the subflow context before returning the newly allocated sock to
the caller.

The fastopen path does not cope with the above unconditionally
dereferencing the subflow context.
References: https://git.kernel.org/stable/c/[PII_REDACTED]9b0ab931c39908b2c99e9fb3c9068b; https://git.kernel.org/stable/c/c0ff6f6da66a7791a32c0234388b1bdc00244917
CVE: CVE-2023-54086
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Add preempt_count_{sub,add} into btf id deny list

The recursion check in __bpf_prog_enter* and __bpf_prog_exit*
leave preempt_count_{sub,add} unprotected. When attaching trampoline to
them we get panic as follows,

[  867.843050] BUG: TASK stack guard page was hit at[PII_REDACTED]d325cf (stack is[PII_REDACTED]a46a15.[PII_REDACTED]7e7b28)
[  867.843064] stack guard page: 0000 [#1] PREEMPT SMP NOPTI
[  867.843067] CPU: 8 PID: 11009 Comm: trace Kdump: loaded Not tainted 6.2.0+ #4
[  867.843100] Call Trace:
[  867.843101]  <TASK>
[  867.843104]  asm_exc_int3+0x3a/0x40
[  867.843108] RIP: 0010:preempt_count_sub+0x1/0xa0
[  867.843135]  __bpf_prog_enter_recur+0x17/0x90
[  867.843148]  bpf_trampoline_[PII_REDACTED]_0+0x2e/0x1000
[  867.843154]  ? preempt_count_sub+0x1/0xa0
[  867.843157]  preempt_count_sub+0x5/0xa0
[  867.843159]  ? migrate_enable+0xac/0xf0
[  867.843164]  __bpf_prog_exit_recur+0x2d/0x40
[  867.843168]  bpf_trampoline_[PII_REDACTED]_0+0x55/0x1000
...
[  867.843788]  preempt_count_sub+0x5/0xa0
[  867.843793]  ? migrate_enable+0xac/0xf0
[  867.843829]  __bpf_prog_exit_recur+0x2d/0x40
[  867.843837] BUG: IRQ stack guard page was hit at[PII_REDACTED]bd8228 (stack is 00000000b23e2bc4..000000006d95af35)
[  867.843841] BUG: IRQ stack guard page was hit at 000000005ae07924 (stack is 00000000ffd69623.[PII_REDACTED]eb594c)
[  867.843843] BUG: IRQ stack guard page was hit at[PII_REDACTED]8320f0 (stack is[PII_REDACTED]4b6438.[PII_REDACTED]d1bcec)
[  867.843842]  bpf_trampoline_[PII_REDACTED]_0+0x55/0x1000
...

That is because in __bpf_prog_exit_recur, the preempt_count_{sub,add} are
called after prog->active is decreased.

Fixing this by adding these two functions into btf ids deny list.
References: https://git.kernel.org/stable/c/095018267c87b8bfbbb12eeb1c0ebf2359e1782c; https://git.kernel.org/stable/c/60039bf72f81638baa28652a11a68e9b0b7b5b2d; https://git.kernel.org/stable/c/b9168d41b83d182f34ba927ee822edaee18d5fc8
CVE: CVE-2023-54087
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

ubi: Fix possible null-ptr-deref in ubi_free_volume()

It willl cause null-ptr-deref in the following case:

uif_init()
  ubi_add_volume()
    cdev_add() -> if it fails, call kill_volumes()
    device_register()

kill_volumes() -> if ubi_add_volume() fails call this function
  ubi_free_volume()
    cdev_del()
    device_unregister() -> trying to delete a not added device,
			   it causes null-ptr-deref

So in ubi_free_volume(), it delete devices whether they are added
or not, it will causes null-ptr-deref.

Handle the error case whlie calling ubi_add_volume() to fix this
problem. If add volume fails, set the corresponding vol to null,
so it can not be accessed in kill_volumes() and release the
resource in ubi_add_volume() error path.
References: https://git.kernel.org/stable/c/234c53e57424992e657e6f4acc00d3df0983176f; https://git.kernel.org/stable/c/2ea7195b195009ecf0046e55361f393ba96d02db; https://git.kernel.org/stable/c/45b2c5ca4d2edae70f19fdb086bd927840c4c309
CVE: CVE-2023-54088
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

blk-cgroup: hold queue_lock when removing blkg->q_node

When blkg is removed from q->blkg_list from blkg_free_workfn(), queue_lock
has to be held, otherwise, all kinds of bugs(list corruption, hard lockup,
..) can be triggered from blkg_destroy_all().
References: https://git.kernel.org/stable/c/083b58373463a6e5ee60ecb135269348f68ad7df; https://git.kernel.org/stable/c/b5dae1cd0d8368b4338430ff93403df67f0b8bcc; https://git.kernel.org/stable/c/c164c7bc9775be7bcc68754bb3431fce5823822e
CVE: CVE-2023-54089
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

virtio_pmem: add the missing REQ_OP_WRITE for flush bio

When doing mkfs.xfs on a pmem device, the following warning was

 ------------[ cut here ]------------
 WARNING: CPU: 2 PID: 384 at block/blk-core.c:751 submit_bio_noacct
 Modules linked in:
 CPU: 2 PID: 384 Comm: mkfs.xfs Not tainted 6.4.0-rc7+ #154
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
 RIP: 0010:submit_bio_noacct+0x340/0x520
 ......
 Call Trace:
  <TASK>
  ? submit_bio_noacct+0xd5/0x520
  submit_bio+0x37/0x60
  async_pmem_flush+0x79/0xa0
  nvdimm_flush+0x17/0x40
  pmem_submit_bio+0x370/0x390
  __submit_bio+0xbc/0x190
  submit_bio_noacct_nocheck+0x14d/0x370
  submit_bio_noacct+0x1ef/0x520
  submit_bio+0x55/0x60
  submit_bio_wait+0x5a/0xc0
  blkdev_issue_flush+0x44/0x60

The root cause is that submit_bio_noacct() needs bio_op() is either
WRITE or ZONE_APPEND for flush bio and async_pmem_flush() doesn't assign
REQ_OP_WRITE when allocating flush bio, so submit_bio_noacct just fail
the flush bio.

Simply fix it by adding the missing REQ_OP_WRITE for flush bio. And we
could fix the flush order issue and do flush optimization later.
References: https://git.kernel.org/stable/c/c1dbd8a849183b9c12d257ad3043ecec50db50b3; https://git.kernel.org/stable/c/c7ab7e45ccef209809f8c2b00f497deec06b29c0; https://git.kernel.org/stable/c/e39e870e1e683a71d3d2e63e661a5695f60931a7
CVE: CVE-2023-54091
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/client: Fix memory leak in drm_client_target_cloned

dmt_mode is allocated and never freed in this function.
It was found with the ast driver, but most drivers using generic fbdev
setup are probably affected.

This fixes the following kmemleak report:
  backtrace:
    [<00000000b391296d>] drm_mode_duplicate+0x45/0x220 [drm]
    [<00000000e45bb5b3>] drm_client_target_cloned.constprop.0+0x27b/0x480 [drm]
    [<00000000ed2d3a37>] drm_client_modeset_probe+0x6bd/0xf50 [drm]
    [<[PII_REDACTED]e5cc9d>] __drm_fb_helper_initial_config_and_unlock+0xb4/0x2c0 [drm_kms_helper]
    [<[PII_REDACTED]9f82ca>] drm_fbdev_client_hotplug+0x2bc/0x4d0 [drm_kms_helper]
    [<[PII_REDACTED]3a69aa>] drm_client_register+0x169/0x240 [drm]
    [<00000000a8c61525>] ast_pci_probe+0x142/0x190 [ast]
    [<[PII_REDACTED]7f19bb>] local_pci_probe+0xdc/0x180
    [<000000004fca231b>] work_for_cpu_fn+0x4e/0xa0
    [<[PII_REDACTED]b85301>] process_one_work+0x8b7/0x1540
    [<[PII_REDACTED]75b17c>] worker_thread+0x70a/0xed0
    [<00000000b0d43cd9>] kthread+0x29f/0x340
    [<000000008d770833>] ret_from_fork+0x1f/0x30
unreferenced object 0xff[PII_REDACTED]a00 (size 128):
References: https://git.kernel.org/stable/c/105275879a80503686a8108af2f5c579a1c5aef4; https://git.kernel.org/stable/c/4b596a6e2d2e0f9c14e4122506dd715f43fcd727; https://git.kernel.org/stable/c/52daf6ba2e0d201640cb1ce42049c5c4426b4d6e
CVE: CVE-2023-54092
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

KVM: s390: pv: fix index value of replaced ASCE

The index field of the struct page corresponding to a guest ASCE should
be 0. When replacing the ASCE in s390_replace_asce(), the index of the
new ASCE should also be set to 0.

Having the wrong index might lead to the wrong addresses being passed
around when notifying pte invalidations, and eventually to validity
intercepts (VM crash) if the prefix gets unmapped and the notifier gets
called with the wrong address.
References: https://git.kernel.org/stable/c/017f686bcb536ff23d49c143fdf9d1fd89a9a924; https://git.kernel.org/stable/c/49a2686adddebe1ae76b4d[PII_REDACTED]56ef6606; https://git.kernel.org/stable/c/8e635da0e0d3cb45e32fa79b36218fb98281bc10
CVE: CVE-2023-54093
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

media: anysee: fix null-ptr-deref in anysee_master_xfer

In anysee_master_xfer, msg is controlled by user. When msg[i].buf
is null and msg[i].len is zero, former checks on msg[i].buf would be
passed. Malicious data finally reach anysee_master_xfer. If accessing
msg[i].buf[0] without sanity check, null ptr deref would happen.
We add check on msg[i].len to prevent crash.

Similar commit:
commit 0ed554fd769a
("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")

[hverkuil: add spaces around +]
References: https://git.kernel.org/stable/c/14b94154a72388b57221a2a73795c0ea61a95373; https://git.kernel.org/stable/c/3dd5846a873938ec7b6d404ec27662942cd8f2ef; https://git.kernel.org/stable/c/4a9763d2bc4a6d6fab42555b9c0b2eefa32585ac
CVE: CVE-2023-54095
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

powerpc/iommu: Fix notifiers being shared by PCI and VIO buses

fail_iommu_setup() registers the fail_iommu_bus_notifier struct to both
PCI and VIO buses.  struct notifier_block is a linked list node, so this
causes any notifiers later registered to either bus type to also be
registered to the other since they share the same node.

This causes issues in (at least) the vgaarb code, which registers a
notifier for PCI buses.  pci_notify() ends up being called on a vio
device, converted with to_pci_dev() even though it's not a PCI device,
and finally makes a bad access in vga_arbiter_add_pci_device() as
discovered with KASAN:

 BUG: KASAN: slab-out-of-bounds in vga_arbiter_add_pci_device+0x60/0xe00
 Read of size 4 at addr c000000264c26fdc by task swapper/0/1

 Call Trace:
   dump_stack_lvl+0x1bc/0x2b8 (unreliable)
   print_report+0x3f4/0xc60
   kasan_report+0x244/0x698
   __asan_load4+0xe8/0x250
   vga_arbiter_add_pci_device+0x60/0xe00
   pci_notify+0x88/0x444
   notifier_call_chain+0x104/0x320
   blocking_notifier_call_chain+0xa0/0x140
   device_add+0xac8/0x1d30
   device_register+0x58/0x80
   vio_register_device_node+0x9ac/0xce0
   vio_bus_scan_register_devices+0xc4/0x13c
   __machine_initcall_pseries_vio_device_init+0x94/0xf0
   do_one_initcall+0x12c/0xaa8
   kernel_init_freeable+0xa48/0xba8
   kernel_init+0x64/0x400
   ret_from_kernel_thread+0x5c/0x64

Fix this by creating separate notifier_block structs for each bus type.

[mpe: Add #ifdef to fix CONFIG_IBMVIO=n build]
References: https://git.kernel.org/stable/c/075a4dcdbc9a5ea793cb8ec8b78a6c0b7636fd52; https://git.kernel.org/stable/c/65bf8a196ba25cf65a858b5bb8de80f0aad76691; https://git.kernel.org/stable/c/6670c65bf863cd0d44ca24d4c10ef6755b8d9529
CVE: CVE-2023-54096
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

soundwire: fix enumeration completion

The soundwire subsystem uses two completion structures that allow
drivers to wait for soundwire device to become enumerated on the bus and
initialised by their drivers, respectively.

The code implementing the signalling is currently broken as it does not
signal all current and future waiters and also uses the wrong
reinitialisation function, which can potentially lead to memory
corruption if there are still waiters on the queue.

Not signalling future waiters specifically breaks sound card probe
deferrals as codec drivers can not tell that the soundwire device is
already attached when being reprobed. Some codec runtime PM
implementations suffer from similar problems as waiting for enumeration
during resume can also timeout despite the device already having been
enumerated.
References: https://git.kernel.org/stable/c/48d1d0ce0782f995fda678508fdae35c5e9593f0; https://git.kernel.org/stable/c/a36b522767f3a72688893a472e80c9aa03e67eda; https://git.kernel.org/stable/c/c40d6b3249b11d60e09d81530588f56233d9aa44
CVE: CVE-2023-54097
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

regulator: stm32-pwr: fix of_iomap leak

Smatch reports:
drivers/regulator/stm32-pwr.c:166 stm32_pwr_regulator_probe() warn:
'base' from of_iomap() not released on lines: 151,166.

In stm32_pwr_regulator_probe(), base is not released
when devm_kzalloc() fails to allocate memory or
devm_regulator_register() fails to register a new regulator device,
which may cause a leak.

To fix this issue, replace of_iomap() with
devm_platform_ioremap_resource(). devm_platform_ioremap_resource()
is a specialized function for platform devices.
It allows 'base' to be automatically released whether the probe
function succeeds or fails.

Besides, use IS_ERR(base) instead of !base
as the return value of devm_platform_ioremap_resource()
can either be a pointer to the remapped memory or
an ERR_PTR() encoded error code if the operation fails.
References: https://git.kernel.org/stable/c/0ad07e02be0d3f0d554653382ffe53ae4879378d; https://git.kernel.org/stable/c/824683dbec234a01bd49a0589ee3323594a6f4cf; https://git.kernel.org/stable/c/ad6481f49fb2c703efa3a929643934f24b666d6a
CVE: CVE-2023-54099
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

fs: Protect reconfiguration of sb read-write from racing writes

The reconfigure / remount code takes a lot of effort to protect
filesystem's reconfiguration code from racing writes on remounting
read-only. However during remounting read-only filesystem to read-write
mode userspace writes can start immediately once we clear SB_RDONLY
flag. This is inconvenient for example for ext4 because we need to do
some writes to the filesystem (such as preparation of quota files)
before we can take userspace writes so we are clearing SB_RDONLY flag
before we are fully ready to accept userpace writes and syzbot has found
a way to exploit this [1]. Also as far as I'm reading the code
the filesystem remount code was protected from racing writes in the
legacy mount path by the mount's MNT_READONLY flag so this is relatively
new problem. It is actually fairly easy to protect remount read-write
from racing writes using sb->s_readonly_remount flag so let's just do
that instead of having to workaround these races in the filesystem code.

[1] https://lore.kernel.org/all/[PII_REDACTED]0006a0df05f6667499@google.com/T/
References: https://git.kernel.org/stable/c/0336b42456e485fda1006b5b411e7372e20fbf03; https://git.kernel.org/stable/c/0ccfe21949bc9f706a86ee7351b74375c0745757; https://git.kernel.org/stable/c/295ef44a2abaf97d7a594b1d4c60d4be3738191f
CVE: CVE-2023-54100
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: qedi: Fix use after free bug in qedi_remove()

In qedi_probe() we call __qedi_probe() which initializes
&qedi->recovery_work with qedi_recovery_handler() and
&qedi->board_disable_work with qedi_board_disable_work().

When qedi_schedule_recovery_handler() is called, schedule_delayed_work()
will finally start the work.

In qedi_remove(), which is called to remove the driver, the following
sequence may be observed:

Fix this by finishing the work before cleanup in qedi_remove().

CPU0                  CPU1

                     |qedi_recovery_handler
qedi_remove          |
  __qedi_remove      |
iscsi_host_free      |
scsi_host_put        |
//free shost         |
                     |iscsi_host_for_each_session
                     |//use qedi->shost

Cancel recovery_work and board_disable_work in __qedi_remove().
References: https://git.kernel.org/stable/c/124027cd1a624ce0347adcd59241a9966a726b22; https://git.kernel.org/stable/c/3738a230831e861503119ee2691c4a7dc56ed60a; https://git.kernel.org/stable/c/5e756a59cee6a8a79b9059c5bdf0ecbf5bb8d151
CVE: CVE-2023-54101
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

driver: soc: xilinx: use _safe loop iterator to avoid a use after free

The hash_for_each_possible() loop dereferences "eve_data" to get the
next item on the list.  However the loop frees eve_data so it leads to
a use after free.  Use hash_for_each_possible_safe() instead.
References: https://git.kernel.org/stable/c/256aace3a5d8c987183ba4832dffb36f48ea7d3b; https://git.kernel.org/stable/c/49fca83f6f3f0cafe5bf5b43e8ee81cf73c2d5e0; https://git.kernel.org/stable/c/c58da0ba3e5c86e51e2c1557afaf6f71e00c4533
CVE: CVE-2023-54102
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: lpfc: Prevent lpfc_debugfs_lockstat_write() buffer overflow

A static code analysis tool flagged the possibility of buffer overflow when
using copy_from_user() for a debugfs entry.

Currently, it is possible that copy_from_user() copies more bytes than what
would fit in the mybuf char array.  Add a min() restriction check between
sizeof(mybuf) - 1 and nbytes passed from the userspace buffer to protect
against buffer overflow.
References: https://git.kernel.org/stable/c/644a9d5e22761a41d5005a26996a643da96de962; https://git.kernel.org/stable/c/a9df88cb31dcbd72104ec5883f35cbc1fb587e47; https://git.kernel.org/stable/c/ad050f6cf681ebb850a9d4bc19474d[PII_REDACTED]
CVE: CVE-2023-54103
Published: 2025-12-24
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2023-54104
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

mtd: rawnand: fsl_upm: Fix an off-by one test in fun_exec_op()

'op-cs' is copied in 'fun->mchip_number' which is used to access the
'mchip_offsets' and the 'rnb_gpio' arrays.
These arrays have NAND_MAX_CHIPS elements, so the index must be below this
limit.

Fix the sanity check in order to avoid the NAND_MAX_CHIPS value. This
would lead to out-of-bound accesses.
References: https://git.kernel.org/stable/c/1f09d67d390647f83f8f9d26382b0daa43756e6f; https://git.kernel.org/stable/c/49e57caf967a969f6b955c88805f2d160910aa12; https://git.kernel.org/stable/c/c6abce60338aa2080973cd95be0aedad528bb41f
CVE: CVE-2023-54105
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

can: isotp: check CAN address family in isotp_bind()

Add missing check to block non-AF_CAN binds.

Syzbot created some code which matched the right sockaddr struct size
but used AF_XDP (0x2C) instead of AF_CAN (0x1D) in the address family
field:

bind$xdp(r2, &(0x7f[PII_REDACTED])={0x2c, 0x0, r4, 0x0, r2}, 0x10)
                                ^^^^
This has no funtional impact but the userspace should be notified about
the wrong address family field content.
References: https://git.kernel.org/stable/c/2fc6f337257f4f7c21ecff429241f7acaa6df4e8; https://git.kernel.org/stable/c/9427584c2f153d0677ef3bad6f44028c60d728c4; https://git.kernel.org/stable/c/c6adf659a8ba85913e16a571d5a9bcd17d3d1234
CVE: CVE-2023-54106
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

net/mlx5: fix potential memory leak in mlx5e_init_rep_rx

The memory pointed to by the priv->rx_res pointer is not freed in the error
path of mlx5e_init_rep_rx, which can lead to a memory leak. Fix by freeing
the memory in the error path, thereby making the error path identical to
mlx5e_cleanup_rep_rx().
References: https://git.kernel.org/stable/c/0582a3caaa3e2f7b80bcb113ad3c910eac15a63e; https://git.kernel.org/stable/c/c265d8c2e25546a6b7ee16d36f2bb79b6160c2c3; https://git.kernel.org/stable/c/c6cf0b6097bf1bf1b2a89b521e9ecd26b581a93a