CVE-2023-53480: kobject: Add sanity check for kset->kobj.ktype in kset_register()
In the Linux kernel, the following vulnerability has been resolved:
kobject: Add sanity check for kset->kobj.ktype in kset_register()
When I register a kset in the following way:
static struct kset my_kset;
kobject_set_name(&my_kset.kobj, "my_kset");
ret = kset_register(&my_kset);
A null pointer dereference exception is occurred:
[ 4453.568337] Unable to handle kernel NULL pointer dereference at \
virtual address 0000000000000028
... ...
[ 4453.810361] Call trace:
[ 4453.813062] kobject_get_ownership+0xc/0x34
[ 4453.817493] kobject_add_internal+0x98/0x274
[ 4453.822005] kset_register+0x5c/0xb4
[ 4453.825820] my_kobj_init+0x44/0x1000 [my_kset]
... ...
Because I didn't initialize my_kset.kobj.ktype.
According to the description in Documentation/core-api/kobject.rst:
- A ktype is the type of object that embeds a kobject. Every structure
that embeds a kobject needs a corresponding ktype.
So add sanity check to make sure kset->kobj.ktype is not NULL.
Security readout for executives and security teams
Plain-English summary
CVE-2023-53480 is a Linux kernel null pointer dereference in kset registration. If kernel code registers a kset without a required type field, the kernel can fault. Public sources describe a stability/denial-of-service style issue, not data theft or remote compromise.
Executive priority
Handle through the normal kernel patch program, with higher priority for systems using custom or third-party kernel modules. Current public evidence does not support emergency treatment, but kernel crash issues can affect availability.
Technical view
The flaw is in kset_register(). A kset with kset->kobj.ktype left NULL could reach kobject_get_ownership() and trigger a NULL pointer dereference. The kernel fix adds a sanity check to ensure kset->kobj.ktype is not NULL before registration proceeds.
Likely exposure
Exposure is most relevant to Linux systems running affected kernel branches and loading in-tree, third-party, or custom kernel code that registers ksets incorrectly. Standard systems without such code paths may have limited practical exposure, but should still consume vendor kernel updates.
Exploitation context
CISA KEV is false in the provided data, and no cited source states active exploitation. Public evidence shows a crash scenario caused by incorrect kernel object initialization. Exploitation would depend on reaching that faulty kernel code path.
Researcher notes
The record lacks CVSS, CWE, and detailed attacker prerequisites. The fix is defensive validation in kset_register(). Treat impact assessment as environment-dependent until distribution advisories clarify affected package versions and reachability.
Mitigation direction
Apply Linux distribution kernel updates that include the referenced stable fixes.
Prioritize hosts using custom, third-party, or out-of-tree kernel modules.
Review vendor advisories for exact fixed package versions.
Avoid loading untrusted or unnecessary kernel modules.
Validation and detection
Check running kernel versions against vendor advisories for CVE-2023-53480.
Review kernel package changelogs for the listed stable commit references.
Inspect custom modules for kset_register() calls with initialized kobj.ktype.
Search kernel logs for oops traces involving kset_register or kobject_get_ownership.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2023-53480 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
8Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Oct 1, 2025, 11:42 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.